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I.  INTRODUCTION 

Effective  planning  is  vital  to  the  success  of  any  business  undertaking.  This  is 
especially  true  in  the  acquisition  of  major  weapon  systems  within  the  Department  of 
Defense.  Even  though  recent  reductions  in  statutory  and  regulatory  requirements  make 
the  Federal  acquisition  process  less  complex,  it  is  still  "apparent  that  sound  acquisition 
planning  is  the  key  to  success."  [Ref  1  :p.  9] 

A  search  of  the  literature  indicates  that  prior  to  the  Competition  in  Contracting  Act 
(CICA)  of  1984,  acquisition  planning  in  some  Government  agencies  may  have  been 
performed  in  a  sporadic  and  fragmented  manner.  Formal  procedures  or  processes,  if 
developed,  may  not  have  been  followed,  and  if  so  were  usually  developed  on  a  program- 
by-program  basis.  Planning  that  did  occur  was  usually  informal,  and  depended 
considerably  on  the  interaction  and  experience  of  the  personnel  involved.  This  lack  of  a 
formal  planning  process  may  have  "led  to  situations  where  the  contracting  officer  had 
inadequate  time  to  conduct  procurement  effectively."  [Ref.  l:p.  9-10] 

The  1984  Competition  in  Contracting  Act  corrected  the  lack  of  formal  planning,  at 
least  indirectly,  by  requiring  that  agencies  "do  a  better  job  of  planning  and  preparing  for 
competitive  procurements."  [Ref.  2:p.  81]  Although  procurement  planning  had  been  done 
in  some  form  or  another  for  at  least  25  years,  CICA  now  required  its  use.  Congress 
expressed  its  belief  that  procuring  agencies  were  not  doing  the  kind  of  planning  necessary 
to  effectively  manage  the  procurement  process.  [Ref.  2:p.  81]   To  correct  this,  Congress 


directed  in  Title  41,  U.S.C.  Section  253a  (a)  (1)  (B)  and  Title  10,  U.S.C.  Section  2305  (a) 
(1)  (A)  (ii)  that  agencies  would  now  "use  advance  procurement  planning." 

The  Federal  Acquisition  Regulation  (FAR)  at  Part  7  defines  acquisition  planning  as 
"the  process  [emphasis  added]  by  which  the  efforts  of  all  the  personnel  responsible  for  an 
acquisition  are  coordinated  and  integrated  through  a  comprehensive  plan  for  fulfilling  the 
agency  need  in  a  timely  manner,  and  at  a  reasonable  cost."  The  FAR  requires  the 
development  of  a  comprehensive  acquisition  plan  as  soon  as  the  agency  need  is 
determined. 

As  a  result  of  OCA,  and  its  shift  toward  competitive  procurements,  acquisition 
planning  now  became  more  necessary  and  formalized.  [Ref  2:p.  81]  Acquisition  plans  are 
required  by  FAR  7.105  to  have  milestones  that  address  all  of  the  technical,  business, 
management,  and  other  significant  considerations  that  will  control  the  acquisition. 
Although  the  FAR  spells  out  all  of  the  elements  of  an  acquisition  plan,  nowhere  does  the 
FAR  spell  out  a  specific  process  to  use  in  developing  an  acquisition  plan.  At  best, 
acquisition  planning  can  best  be  thought  of  as  an  iterative  process  that  becomes 
increasingly  more  definitive  as  the  weapon  system  progresses  from  program  initiation 
through  post-production  support.  [Ref.  3:p.  3.3-3.4] 

The  underlying  process,  or  processes,  that  drive  the  development  of  an 
acquisition  plan  are  not  well  understood  or  defined.  In  a  study  conducted  by  the  Logistics 
Management  Institute  (LMI)  of  several  Government  agencies,  it  found  that  no 
documented  acquisition  planning  process  existed  prior  to  LMTs  efforts  to  develop  one. 


Many  organizations  depended  on  their  staffs  to  handle  the  next  acquisition  plan  "just  like 
they  did  the  last  one."  [Ref.  4:p.  378]  Most  often  the  only  record  or  insight  that  existed  of 
the  acquisition  planning  process  was  in  "the  memory  of  the  participants,  particularly  for 
steps  at  the  interface  between  components."  The  elements  of  an  acquisition  plan  may  be 
relatively  well  defined,  but  the  process  of  generating,  or  formalizing,  the  acquisition  plan 
may  not  be  as  well  understood.  [Ref.  4:p  382] 

In  order  to  begin  understanding  acquisition  planning  as  a  process,  the  term  process 
must  first  be  understood.  A  process  is  a  structured  and  measurable  set  of  activities 
designed  to  produce  a  specific  output.  Processes  are  centered  around  how  things  are 
done,  as  opposed  to  what  is  to  be  done,  such  as  an  acquisition  plan.  Typically,  processes 
have  a  beginning,  an  end,  and  a  clearly  identifiable  input  and  output.  Processes  cut 
through  the  typical  hierarchical  and  vertical  structures  associated  with  organizations. 
"Whereas  an  organization's  hierarchical  structure  is  typically  a  slice-in-time  view  of 
responsibility  and  reporting  relationships,  its  process  structure  is  a  dynamic  view  of  how 
the  organization  delivers  value."  [Ref.  30:p.  6] 

Many  business  processes  "are  characterized  by  a  mode  of  operation  in  which  work 
flows  in  a  serial  fashion  from  one  process  to  another."  [Ref.  4:p.  378-379]  When  these 
administrative  processes  break  down,  "patches"  are  applied  to  fix  the  problem.  Over  time, 
a  series  of  patches  will  most  likely  produce  a  poorly  operating  process.  Fragmentation 
and  splintering  will  result  and  further  reduce  the  efficiency  of  this  process.    Perhaps  the 


only  way  to  effectively  correct  this  problem  is  by  redesigning,  or  reengineering,  the 

existing  business  process.  [Ref.  4:p.  379] 

Michael  Hammer  and  James  Champy  in  their  1993  book,  Reengineering  the 

Corporation:    A    Manifesto   for    Business    Revolution,    defined    Business    Process 

Reengineering  (BPR)  as: 

fTJhe  fundamental  rethinking  and  radical  redesign  of  business 
processes  to  achieve  dramatic  improvements  in  critical,  contemporary 
measures  of  performance  such  as  cost,  quality,  service,  and  speed. 

Within  this  definition,  Hammer  gave  four  key  words  that  provide  the  essence  of 

reengineering.      The   first   word,   fundamental,   provides  the   most   basic   notion   of 

reengineering;  Why  do  we  do  what  we  do?  It  takes  nothing  for  granted,  ignores  what  is, 

and  concentrates  on  what  should  be.  The  second  key  word,  radical,  means  getting  to  the 

root  of  the  problem.     In  context,  it  means  disregarding  all  existing  procedures  and 

inventing  completely  new  ways  of  doing  things.     The  third  word,  dramatic,  means  a 

quantum  leap  in  performance,  not  a  marginal  or  incremental  improvement  such  as  with 

Total  Quality  Management  (TQM).    A  50%  or  greater  improvement,  not  a  five  or  ten 

percent  improvement.    And  the  last,  and  most  important  word,  processes,  is  used  within 

reengineering  to  mean  a  collection  of  business  activities  or  tasks  that  takes  inputs  and 

provides  an  output  of  value  to  a  customer.   Reengineering  is  different  in  that  it  does  not 

focus  on  discrete  tasks,  jobs,  people  or  structures,  but  on  a  business  process  as  a  whole. 

[Ref.  5:p.  32-36] 


In  the  most  basic  sense,  reengineering  is  about  starting  over  with  a  blank  sheet  of 
paper.  It  is  about  inventing  new  approaches  to  business  processes  that  may  bear  no 
resemblance  to  existing  processes.  It  is  not  about  restructuring  or  downsizing  merely  for 
the  sake  of  cutting  budgets.  Nor  is  BPR  about  new  ways  to  reorganize  or  eliminate 
bureaucracies.  It  differs  from  Total  Quality  Management  (TQM)  in  that  TQM  is  about 
continuous,  iterative  improvements  approach  to  business  processes.  BPR  innovates. 
Finally,  BPR  is  not  the  same  as  automation.  Automation,  in  many  cases  may  only  provide 
a  more  efficient  way  of  performing  a  broken  process.  [Ref.  5:p.  47-49] 

Within  BPR,  automation  is  considered  an  enabler  that  fosters  dramatic 
improvements  in  business  process.  However,  automation  of  business  processes  has  not 
produced  the  dramatic  improvements  in  productivity  as  previously  envisioned  or  hoped. 
Private  corporations  have  spent  billions  of  dollars  over  the  last  forty  years  to  automate 
tasks  with  no  fundamental  improvement  in  performance.  There  has  been  a  tremendous 
outlay  of  organizational  capital  on  automation,  usually  with  questionable  or  disappointing 
returns.  [Ref.  5:p.  25] 

Much  of  this  disappointment  with  technology  in  BPR  is  attributable  to  the 
application  of  automation  over  the  existing  business  process  found  within  an  organization. 
Information  technology  (IT)  sped  up  existing  business  processes,  but  did  little,  if  anything, 
to  change  imbedded  process  deficiencies  that  the  successful  application  of  BPR  would 
demand.     "Automating  existing  process  with  information  technology  is  analogous  to 


paving  cow  paths.    Automation  simply  provides  more  efficient  ways  of  doing  the  wrong 
kinds  of  things."  [Ref.  5:p.  48] 

Information  technology  has  assisted  the  process  of  developing  acquisition  plans 
mainly  through  word  processing,  spreadsheet,  and  limited  database  applications.  For 
instance,  development  of  the  Naval  Sea  Systems  Command  (NAVSEA)  sponsored  Master 
Acquisition  Planning  Program  (MAPP)  consolidates  the  over  100  plans  potentially 
referenced  in  the  typical  acquisition  plan.  Its  goal  is  "to  improve  the  planning  process 
through  enhanced  communication,  more  efficient  use  of  resources,  and  reduced  cycle 
time."  However,  MAPP  may  have  little  or  no  effect  on  the  underlying  process  that 
produces  the  acquisition  plan.  [Ref.  6: p.  i-iii] 

A.         RESEARCH  QUESTIONS 

The  primary  research  question  is: 

How  can  the  acquisition  planning  process  for  a  major  weapons  system  be 
reengineered  to  effect  order-of-magnitude  improvements  in  performance?  Subsidiary 
questions  would  include: 

I.  What  are  the  principal  elements  that  make  up  the  acquisition  planning  process? 

II.  What  reengineering  or  process  improvements  have  been  made  to  the  acquisition 
system  and  what  effect  have  these  had  on  acquisition  planning? 

III.  What  has  been  the  role  of  IT  in  these  process  improvement  efforts  and  what  effects 
has  the  introduction  of  IT  had  on  the  process? 


A.  What  effect  did  the  initial  introduction  of  IT  have  on  the  acquisition 
process  in  terms  of  productivity? 

B.  How  has  the  introduction  of  IT  into  the  acquisition  process  affected  both 
personnel  and  organizational  structures? 

C.  What  is  the  current  state  of  IT  in  the  acquisition  planning  process  and  what 
changes  will  take  place  in  the  immediate  future? 

IV.  What  pathologies  and  faults  remain  in  the  current  acquisition  planning  process  and 
what  technologies  or  redesigns  can  be  implemented  to  overcome  them? 

V.  What  steps  are  required  to  successfully  implement  these  technologies  or  redesigns? 

VI.  How  would  the  employment  of  the  BPR  model  change  future  implementations  of 
IT  in  the  acquisition  planning  process? 

B.         RESEARCH  METHOD 

Information  used  in  the  preparation  of  this  thesis  was  obtained  through  literature 
and  field  research.  Online  library  catalogs  and  periodical  databases  were  searched. 
Additionally,  a  comprehensive  search  of  the  Internet  was  conducted  using  various  search 
engines.  Relevant  books,  articles  and  other  documents  cited  as  a  result  of  these  literature 
searches  are  in  the  List  of  References.  Some  of  the  material  was  brought  to  the 
researcher's  attention  during  phone  conversations  and  interviews. 

A  major  system  command,  the  Naval  Air  System  Command  (NAVAIR)  was 
approached  to  provide  a  source  of  current  and  relevant  information  on  the  acquisition 
planning  process.  Command  instructions  and  other  published  guidance  was  used  to  assess 


the  NAVAIR  acquisition  planning  process  and  improvements  that  could  be  attained  using 
information  technology.  However,  it  was  not  treated  as  a  case  study  in  order  to  critique 
NAVAIR' s  efficiency  in  developing  particular  acquisition  plans,  its  programs  or  their 
personnel.  In  reality  it  was  chosen  for  two  reasons. 

First,  NAVAIR' s  use  of  a  core  competency  approach  to  the  management  of  its 
planning  process  was  conducive  to  effectively  allowing  the  studying  of  the  process.  Core 
competency  requires  management  to  think  much  more  carefully  about  the  firms  business 
activities.  [Ref.  42:p.  66]  This  focus  on  core  competencies  eliminates  many  of  the 
extraneous  problems  associated  with  the  poor  management  of  people  and  resources. 
Second,  NAVAIR  is  very  proactive  in  the  study  and  automation  of  acquisition  processes, 
providing  a  fertile  area  for  research.  Combined,  this  allowed  the  researcher  to  effectively 
study  the  underlying  acquisition  planning  process  and  use  it  as  a  practical  input  to  the  BPR 
analysis. 

Additional  information  was  gathered  from  other  organizations  that  develop  or 
acquire  acquisition  planning  software  systems.  These  included  systems  used,  or  planned 
for  use  in  the  near  term,  by  the  Departments  of  the  Navy,  Air  Force  and  Department  of 
Defense  (DoD). 

C.         SCOPE  OF  THESIS  RESEARCH 

The  main  thrust  of  this  thesis  is  on  the  application  of  BPR  to  the  process  of 
developing  an  acquisition  plan  within  a  major  system  command.    It  also  includes,  for 


background  and  clarification,  a  limited  analysis  of  the  organizational,  legislative  and 
personnel  factors  that  contribute  to,  or  affect,  an  acquisition  plan. 

The  contribution  of  IT  to  the  process  of  developing  an  acquisition  plan  is  examined 
as  an  integral  part  of  the  overall  acquisition  process,  not  as  a  stand  alone  factor.  This 
thesis  attempts  to  apply  the  BPR  model  with  the  goal  of  presenting  a  new  process  for 
developing  acquisition  plans  that  takes  advantage  of,  and  leverages,  the  power  of  modern 
IT.  Based  on  the  analysis  using  BPR,  a  new  process  for  developing  acquisition  plans  will 
be  suggested  for  future  study. 

This  thesis  does  not  look  at  IT  from  a  micro  level  view.  No  new  code  or  software 
development  is  anticipated,  although  some  areas  ripe  for  development  may  be  suggested. 
Examples  would  include  the  use  of  collaborative  integrated  design  (CTD)  software, 
Knowledge-Based  Systems  (KBS),  Artificial  Intelligence  (AI),  software  agents  and  expert 
systems  in  the  development  of  an  acquisition  plan. 
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H.  BACKGROUND 

A.         INTRODUCTION 

The  Defense  acquisition  system  is  extremely  complex.  Literally  hundreds  of 
thousands  of  employees  work  within  an  administrative  system  designed  to  execute  millions 
of  contract  actions  each  year.  Major  weapon  systems,  involving  billions  of  dollars,  push 
the  envelope  of  technology  by  attempting  to  achieve  performance  levels  not  previously 
imagined.  The  combination  of  all  these  factors  causes  high  levels  of  contract  uncertainty 
and  considerable  technical  risk  in  the  developmental  process  for  a  major  weapon  system. 
[Ref.  7:p.  109] 

The  risk  represented  in  these  inherently  complex  acquisitions  manifests  itself  in  all 
phases  of  the  program  or  process.  It  is  measured  by  the  inability  to  achieve  overall 
program  goals  and  objectives  within  defined  cost,  schedule,  and  technical/performance 
constraints.  The  two  components  of  this  measure  are  the  probability  of  failing  to  achieve 
a  particular  goal  or  outcome  and  the  consequences  of  failing  to  achieve  the  goal  or  desired 
outcome.  Risk  management  is  the  term  applied  to  the  act  or  practice  of  controlling  risk 
within  a  program.  It  includes  identifying  and  tracking  risk  drivers,  developing  risk 
mitigation  plans  and  continuously  assessing  risk  to  determine  how  it  changes  over  the 
course  of  the  program. 

Given  that  risk  is  present  throughout  all  phases  of  a  program,  failure  to  adequately 
manage  and  anticipate  it  can  have  an  extremely  adverse  affect  on  a  program's  success.  The 
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primary  method  to  manage  and  control  risk  is  an  early  and  comprehensive  planning  effort 
followed  by  the  aggressive  execution  of  that  plan.  [Ref  8.]  Within  DoD  this  planning 
effort  is  partly  managed  by  two  formal  documents,  the  acquisition  strategy  and  the 
acquisition  plan. 

B.         ACQUISITION  STRATEGY  AND  PLANNING 

The  acquisition  strategy  provides  a  top  level  description  that  is  used  by  senior 
decision  makers  to  assess  whether  a  program  makes  good  business  sense,  effectively 
implements  laws  and  policies,  and  reflects  top  management's  priorities.  Once  approved  by 
the  Milestone  Decision  Authority  (MDA),  the  acquisition  strategy  provides  the  basis  for 
more  detailed  planning.  [Ref.  9.] 

The  Program  Manager  (PM)  is  responsible  for  developing  the  acquisition  strategy. 
In  the  most  basic  sense,  the  acquisition  strategy  is  "the  framework  for  planning, 
organizing,  staffing,  coordinating,  and  leading  a  program.  It  provides  a  master  schedule 
for  research,  development,  test,  production,  fielding,  and  other  activities  essential  for 
program  success  and  for  formulating  functional  strategies  and  plans."  [Ref.  10: p.  1-1] 
This  document  covers  the  program  from  initiation  through  post-production  support  and 
includes  all  critical  events  necessary  for  the  success  of  the  program.  By  its  very  nature, 
the  acquisition  strategy  is  a  plan  that  evolves  through  an  iterative  process,  becoming 
increasingly  more  defined  as  the  program  matures  through  its  various  phases.  The 
acquisition  strategy  provides  a  substantial  portion  of  the  functional  acquisition  plan.  [Ref. 
3:p.  3.3-3.4] 
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The  acquisition  plan  is  also  the  responsibility  of  the  PM,  but  the  actual  preparation 
is  performed  by  the  Contracting  Officer  (CO).  Acquisition  plans  differ  from  strategies  in 
that  they  are  functional,  execution  level  oriented  documents.  [Ref.  10:p.  4-3]  It 
coordinates  and  integrates  planning  of  all  functions  needed  to  execute  the  acquisition 
program.  The  Federal  Acquisition  Regulation  (FAR)  requires  acquisition  planning  for  all 
procurement,  and  the  Defense  Federal  Acquisition  Regulation  Supplement  (DFARS) 
requires  PMs  to  prepare  written  acquisition  plans  for  most  acquisitions  exceeding  $5 
million.  [Ref.  9.] 

C.         ACQUISITION  PLANNING  REQUIREMENTS  OF  FAR  PART  7 

The  FAR,  Part  7,  requires  federal  agencies  to  perform  acquisition  planning  for  all 
acquisitions.  This  planning  should  include  and  integrate  the  efforts  of  all  personnel 
responsible  for  significant  aspects  of  the  acquisition  with  the  purpose  of  ensuring  that  the 
Government  fulfills  its  needs  in  the  "most  effective,  economical,  and  timely  manner." 
Although  it  does  not  say  a  written  plan  should  be  prepared  in  every  case,  it  does  say  that 
agency  heads  should  establish  criteria  at  which  increasingly  complex  acquisitions  may 
require  written  acquisition  plans. 

Acquisition  planning  as  envisioned  by  the  FAR  encourages  acquisition  planning  as 
soon  as  the  agency's  need  is  identified.  One  of  the  key  points  of  the  FAR  is  the 
requirement  that  the  acquisition  planner  form  a  team  consisting  of  "all  those  who  will  be 
responsible  for  significant  aspects  of  the  acquisition,  such  as  contracting,  fiscal,  legal,  and 
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technical  personnel."  Additionally,  this  involvement  must  occur  "early"  in  the  planning 
process  and  should  be  done  with  requirements  and  logistics  personnel. 

Along  with  considering  the  technical  and  logistical  concerns,  the  written  plan  must 
address  all  of  the  "technical,  business,  management,  and  other  significant  considerations 
that  will  control  the  acquisition."  Specific  contents  of  a  plan  may  vary  depending  on  the 
"nature,  circumstances,  and  stage  of  the  acquisition."  However,  in  actually  writing  and 
preparing  the  plan,  the  planner  is  required  to  follow  and  address  mandatory  sections  of 
the  FAR  at  Part  7  (See  Appendix  A). 

The  written  acquisition  plan  as  prescribed  by  the  FAR  can  be  an  inherently 
complex  document.  It  is  nominally  broken  down  into  two  sections.  The  first  section  deals 
with  the  background  and  objectives  of  the  acquisition  and  "considers  what  the 
Government  is  buying,  how  it  will  evaluate  price  and  other  cost  factors,  where  it  is  to  be 
performed,  and  the  risk  involved."  [Ref  l:p.  22]  The  second  section,  the  plan  of  action, 
describes  the  steps  the  agency  will  take  to  procure  the  weapon  system. 

The  complexity  issue  arises  from  all  of  the  divergent  and  overlapping  factors  laid 
out  in  the  acquisition  planning  requirements  of  FAR  Part  7.  For  instance,  consideration 
must  be  given  to  logistics  support  issues  throughout  the  life  of  the  acquisition  plan.  If 
changes  occur  to  Integrated  Logistics  Support  plans  (as  invariably  will  occur),  this  input 
must  be  reflected  in  the  acquisition  plan  if  the  desired  results  are  to  occur.  By  some 
estimates,  over  100  plans  are  developed  during  the  acquisition  planning  process  for  a 
major  weapons  system.  [Ref.  11] 
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D.         NAVY  AQUISITION  PLANNING  REQUIREMENTS 

The  Navy  Acquisition  Planning  Guide  (APG)  states  that  the  Acquisition  Plan  (AP) 
documents  the  results  of -advanee  acquisition  planning.  It  includes,  usually  by  reference, 
other  plans  developed  during  the  acquisition  planning  process  such  as  the  Integrated 
Logistics  Support  Plan  (ILSP),  the  Test  and  Evaluation  Master  Plan  (TEMP),  or  the  Navy 
Training  Plan  (NTP).  When  approved,  it  represents  a  formal  agreement  between  the 
acquisition  Program  Manager  (PM),  Procuring  Contracting  Officer  (PCO),  Chief  of  the 
Contracting  Office,  and  the  Program  Executive  Officer  (PEO)  as  to  how  the  PM  will 
execute  the  program.  Within  the  Department  of  the  Navy,  a  written  AP  is  required  for  the 
following  acquisitions:  [Ref  12] 

•  All  ship  construction  programs  and  Service  Life  Extension  Programs  (SLEP). 

•  Acquisitions  for  development  programs  estimated  at  $5,000,000  or  more. 

•  Acquisitions  for  production  or  services  estimated  at  $30,000,000  or  more  for 
all  years  and  $15,000,000  or  more  for  any  fiscal -year. 

•  Any  other  acquisition  as  designated  by  the  Assistant  Secretary  of  the  Navy 
(ASN)  or  higher  authority. 

APs  are  not  required  for  procurements  such  as  military  construction,  commercial  items, 
spare  parts,  overhauls,  and  final  buy  out  or  one-time  buys. 

1.         Naval  Aviation  Systems  Command  Requirements 

At  the  Naval  Air  Systems  Command,  the  acquisition  plan  is  the  principal  document 
used  by  the  PM  for  program  review  and  oversight.    As  a  matter  of  practice,  the  AP  is 
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initially  prepared  at  the  same  time  that  available  funds  and  resources  are  identified  to  solve 
a  particular  need.  Because  of  this,  the  AP  is  linked  directly  to  the  Future  Year  Defense 
Program  (FYDP)  and  becomes  the  primary  means  to  introduce  the  scope  and  magnitude 
of  a  particular  program  into  the  budget  process.  [Ref.  13:p.  2-1] 

E.         SUMMARY 

Acquiring  a  major  weapon  system  is  an  inherently  complex  undertaking  because  of 
its  large  dollar  value  and  technological  requirements.  Because  of  this,  considerable  risk  is 
present  in  all  phases  of  the  acquisition.  The  development  of  an  acquisition  strategy  and 
plan  is  intended  to  lower  risk  by  defining  key  elements:  performance,  risk,  and  cost. 
Acquisition  plans  act  as  vehicles  to  combine  other  functional  plans  into  a  coherent  whole 
that  the  PM  uses  to  manage  the  overall  acquisition. 

A  thorough  search  of  the  literature  revealed  that  acquisition  planning  is 
predominately  concerned  with  the  functional  and  administrative  aspects  such  as  who  is 
responsible  for  their  development,  policies  to  follow  in  development,  and  the  form  plans 
should  take  when  completed.  Thus,  what  is  required  to  be  in  a  formal  acquisition  plan  or 
strategy  is  generally  well  defined.  How  we  plan  for  the  acquisition  of  a  major  weapon 
system  is  less  certain  and  is  frequently  left  to  the  discretion  of  those  involved.  The  focus  is 
on  the  product  and  not  on  the  process.  Although  acquisition  planning  is  defined  as  a 
process  in  the  FAR,  little  is  actually  written  that  describes  the  underlying  process. 
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m.  IMPROVEMENTS  TO  THE  ACQUISITION  SYSTEM 

A.         INTRODUCTION 

Improvements  in  the  acquisition  system  have  come  about  as  a  result  of  both 
internal  and  external  pressures.  Internally,  changes  that  occurred  in  the  acquisition  of 
major  weapon  systems  were  driven  by  the  growing  complexity  of  these  systems  since 
World  War  II.  Technological  changes  combined  with  increasing  cost  made  previous 
organization  methods  unsuitable  for  managing  the  intricate  weapon  systems  now 
demanded  by  the  war  fighter.  This  resulted  in  the  evolution  of  the  project  management 
approach  when  acquiring  major  weapons  systems. 

Externally,  other  forces  acted  to  improve  the  acquisition  system.  Over  the  years 
Congress  has  periodically  taken  the  initiative  to  improve  or  influence  the  acquisition  of 
defense  systems.  Major  legislative  actions  include  the  Competition  in  Contracting  Act 
(CICA)  and,  more  recently,  the  Federal  Acquisition  Streamlining  Act  (FASA). 

Of  relevance  here  is  to  what  extent  have  changes  to  the  acquisition  system,  both 
internal  and  external,  influenced  the  process  of  planning  for  these  acquisitions. 
Understanding  of  the  intent  of  these  improvements  to  the  acquisition  system  may  shed 
some  light  on  where  the  focus  has  traditionally  been.  In  some  cases,  changes  evolved  or 
were  initiated  that  applied  directly  to  the  process.  And,  in  other  cases,  the  change  may 
have  focused  more  on  achieving  a  desired  outcome  with  little  thought  for  the  underlying 
process. 
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B.         ORGANIZATIONAL  IMPROVEMENTS 

As  stated  by  Michael  Hammer,  "There  are  some  differences  between  the  private 
and  public  sectors,  but  it's  my  experience  that  differences  are  much  less  important  than 
similarities."  [Ref.  14]  Most  private  industrial  corporations  are  organized,  for  internal 
operations,  along  functional  lines  as  are  their  Government  counterparts.  [Ref.  2: p.  120- 
121]  The  underlying  cause  for  any  differences  between  the  two  is  that  Government 
organizations  have  somewhat  different  goals  and  objectives.  [Ref.  15:p.  1-1]  These  would 
include  the  fulfillment  of  social  and  economic  goals  and  objectives  such  as  those  for 
Socially  Disadvantaged  and  Minority  Firms,  Federal  Prison  Industries,  Buy  American  Act, 
and  Small  Business  Act.  [Ref.  2:p.  1  and  Ref.  16:pg.  8-9] 

Within  the  DoD  slightly  different  procurement  organization  structures  have 
developed  in  response  to  the  rigorous  demands  of  developing  a  major  weapon  system.  To 
comprehend  the  difficulty  of  planning  for  an  acquisition  requires  an  understanding  of  the 
complex  business  and  administrative  systems  prevalent  in  procurement  organizations. 
These  systems  employ  planning  and  control  functions  that  are  sometimes  at  odds  with  the 
traditional  hierarchical  approach  found  in  the  management  of  many  organizations.  [Ref. 
2:p.  120-121] 

1.  Development  of  the  Project  Management  Organization 

Since  World  War  II  the  approach  to  acquisition  management  and  organization  has 
changed  considerably.  One  reason  has  been  the  constantly  growing  change  in  the 
technical  complexity  and  the  sheer  size  of  weapon  systems  acquisitions.     As  weapon 
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systems  became  more  complex  and  technologically  challenging,  the  ability  of  traditional 
bureaucratic  organizations  to  coordinate  and  control  the  actions  of  virtually  hundreds  of 
other  organizations  and  thousands  of  people  proved  to  be  unrealistic.  [Ref.  2:  p.  120] 

The  principles  of  division  of  labor  and  hierarchical  control  of  organizations 
appeared  to  be  ineffective  when  applied  to  the  acquisition  and  management  of  highly 
visible,  complex,  and  costly  weapon  systems.  When  it  became  apparent  that  these 
management  techniques  did  not  possess  the  flexibility  and  robustness  necessary  for 
success,  new  management  approaches  were  developed.  [Ref.  2:p.  120-121] 

The  chief  change  that  evolved  in  the  acquisition  of  weapon  systems  was  the 
development  of  the  Project  or  Program  Management  approach.  Program  management 
tends  to  violate  traditional  management  structures  such  as  lines  of  authority,  span  of 
control,  unity  of  command,  and  task  specialization.  Under  project  management,  a  parent 
organization  establishes  the  project  and  assigns  the  personnel.  Upon  completion  of  the 
project,  the  temporary  organization  disbands  and  the  personnel  are  reabsorbed  back  into 
the  parent  organization.  Program  management  appears  to  be  one  of  the  current 
approaches  used  in  managing  complex  undertakings.  [Ref.  2:p.  120-121] 

There  are  two  prevalent  organizational  structures  used  in  project  management:  the 
project  organization  and  matrix  organizations.  Project  organizations  are  more  routinely 
used  in  laboratories  and  advanced  development  program  offices.  In  this  organization, 
project  team  members  report  directly  to  the  project  manager  rather  than  to  a  functional  or 
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line  manager.  Team  members  from  a  variety  of  disciplines  are  integrated  into  a  single  unit 
that  supports  one  project  at  a  time.  [Ref.  17:p  22.2-22.3] 

Major  weapon  systems  are  more  frequently  managed  in  a  matrix  organization 
referred  to  as  program  office  or  system  program  office  (SPO).  In  this  organization 
structure,  the  program  office  is  managed  by  a  program  director  or  a  program  manager 
(PM)  who  normally  reports  to  a  program  executive  officer  (PEO).  Under  the  PM  are  a 
number  of  functional  areas  such  as  contracts,  logistics,  and  systems  engineering  controlled 
by  division  heads.  The  program  office  also  includes  a  projects  division  comprised  of 
project  managers.  Project  managers  may  be  responsible  for  specific  subsystems, 
integration  projects,  or  system  modification  efforts.  They  may  also  be  responsible  for 
multiple  projects  depending  on  the  size  of  the  undertaking.  [Ref.  17:p.  22.2-22.3] 

2.         Development  of  the  Integrated  Product  Team 

Until  recently,  matrix  organizations  have  been  the  prevalent  means  of  managing  the 
acquisition  of  a  major  weapon  systems  program.  However,  Integrated  Product  Teams 
(IPT)  are  rapidly  surfacing  as  the  primary  method  for  controlling  large  undertakings.  In 
the  latest  version  of  the  DoD  5000.2-R  the  Secretary  of  Defense  "directed  that  the 
Department  of  Defense  perform  as  many  acquisition  functions  as  possible,  including 
oversight  and  review,  using  EPTs  "  Additionally,  the  Secretary  decreed  that  "IPTs 
would  be  composed  of  representatives  from  all  appropriate  functional  disciplines  working 
together  to  build  successful  programs  and  enabling  decision-makers  to  make  the  right 
decision  at  the  right  time."  [Ref.  3: p.  1-7] 
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IPTs  may  overcome  some  of  the  more  traditional  problems  still  present  in  matrix 
organizations.  Even  though  independent  technical  organizations  such  as  engineering, 
testing,  and  procurement  provide  matrix  support  to  the  PM,  layered  functional 
management  still  exists.  Time  consuming  meetings,  briefings,  and  staffing  requirements 
may  slow  the  acquisition  process  and  decision  making.  Additionally,  vestiges  of  the 
functional  organization  remain,  vying  for  limited  program  management  office  resources. 
This  tends  to  result  in  the  management  "stovepipes"  and  inefficient  communications,  those 
things  that  the  matrix  organization  originally  sought  to  remove.  [Ref  18:p.  165] 

One  result  of  implementing  IPTs  in  the  acquisition  process  is  a  flatter  organization 
with  a  streamlined  decision  making  process.  A  flatter  organization  moves  decision  making 
down  to  the  lowest  possible  level.  These  benefits  manifest  themselves  as  one  would 
expect — reduced  development  time,  lower  personnel  cost,  and  improved  integration  of  the 
finished  product.  [Ref.  18:p.  164] 

One  inevitable  problem  cited  with  these  new  organizational  structures  is  the 
conflict  that  arises  between  project  managers  and  the  vestiges  of  traditional  organizations, 
the  functional  division  managers.  This  conflict  arises  out  of  the  power  struggle  as  each  of 
these  managers  vies  for  the  organization's  resources.  Dilemmas  arise  between  team 
members  regarding  priorities,  commitments  and  allegiances.  If  not  dealt  with  in  a  timely 
manner,  severe  problems  can  affect  the  acquisition.  [Ref.  17: p.  22.6] 
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C.         HUMAN  RESOURCE  IMPROVEMENTS 

Since  enactment  of  CICA  in  1984,  there  has  been  an  acceleration  in  procurement 
initiatives  undertaken  by  Congress.  [Ref.  2:p.  79]  This  rapidly  changing  environment  will 
most  likely  require  personnel  who  are  capable  of  understanding  and  implementing  those 
changes.  If  the  acquisition  workforce  can  not  comprehend  important  process  changes  or 
their  effect  on  the  overall  system,  it  is  not  likely  that  those  processes  will  succeed.  In 
recognition  of  the  fact  that  people  are  the  key  element  to  the  success  of  any  process 
change,  the  Congress  and  the  Department  of  Defense  promulgated  a  number  of  changes  in 
the  career  management  of  individuals  involved  in  the  acquisition  process.  These  changes 
have  included  implementation  of  the  Defense  Acquisition  Workforce  Improvement  Act 
(DAWIA),  the  establishment  of  a  consortium  of  acquisition  schools  under  the  leadership 
of  the  Defense  Acquisition  University,  and  the  Defense  Management  Review. 

1.  Defense  Acquisition  Workforce  Improvement  Act 

A  possibly  lasting  change  in  the  management  of  personnel  involved  in  the 
acquisition  process  has  been  the  DAWIA.  Although  many  studies  previously  conducted 
on  this  issue  proposed  changes  in  the  management  of  acquisition  personnel,  few  succeeded 
or  carried  the  weight  of  change  as  the  DAWIA.  Signed  into  law  by  the  President  on 
November  5,  1990,  it  brought  together  improvements  previously  only  suggested  by 
studies  such  as  the  Packard  Commission  Report  and  the  China  Lake  Demonstration 
Project.  [Ref.  2:p.  107-110] 
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The  DAWIA  differed  from  previous  legislative  efforts  in  that  it  looked  at 
underlying  weaknesses  in  the  management  of  acquisition  programs  and  identified 
personnel  education  and  training  as  the  key.  It  avoided  the  common  legislative  remedy  of 
adding  additional  layers  of  management  and  oversight  to  correct  previous  failures  in  the 
acquisition  process.  The  general  intent  of  DAWIA  was  to  improve  the  acquisition 
process  by  strengthening  and  improving  the  professionalism  of  the  individuals  responsible 
for  the  process,  the  acquisition  workforce.  [Ref.  2:p.  107-1 10] 

The  DAWIA  identified  many  problems  in  human  resources  management  within 
DoD.  A  principal  weakness  identified  had  to  do  with  the  short  tenure  of  incumbent 
acquisition  personnel,  a  lack  of  career  incentives,  the  inflexibility  in  the  current  civilian 
personnel  system  and  a  lack  of  qualification  standards  for  appointment  to  key  acquisition 
positions.  Congress  corrected  many  of  these  shortcomings  by  requiring  the  Secretary  of 
Defense  to  take  several  actions,  the  more  significant  include;  (1)  establish  policies  and 
procedures  to  manage  the  acquisition  workforce,  (2)  the  establishment  of  an  "acquisition 
corps,"  and  (3)  the  establishment  of  a  Defense  acquisition  university  structure.  [Ref.  2:p. 
109-110] 

Although  the  requirements  of  DAWIA  were  far  ranging,  the  actual  effects  on  the 
acquisition  process  are  less  well  known.  As  of  this  writing,  almost  four  years  have  passed 
since  the  last  mandatory  provision  of  DAWIA  was  enacted  in  1993,  yet  the  full  effects  are 
not  yet  known.     As  with  many  Government  process  improvements,  little  effort  was 
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expended  to  establish  the  structures  and  mechanisms  required  to  collect  useful  data  and 
identify  emerging  trends.  [Ref.  19:p.  97] 

2.         The  Defense  Management  Review  (DMR) 

The  Defense  Management  Review  was  a  response  to  a  presidential  directive  in 
National  Security  Review  (NSR-11)  to  develop  a  plan  for  fully  implementing  the 
recommendations  of  the  Packard  Commission  and  the  Goldwater-Nichols  Defense 
Reorganization  Act.  The  DMR  examined  a  broad  range  of  issues  within  DoD  and  called 
for  management  improvement  actions  in  various  areas. 

Within  the  acquisition  community,  the  DMR  highlighted  the  need  for  improving 
the  human  resource  element.  The  DMR  shared  many  of  the  improvements  called  for  by 
DAWIA  with  regard  to  personnel  issues.  It  also  called  for  the  creation  of  "small,  high 
quality  staffs"  supported  by  strong  initiatives  to  "reduce  management  layers,  motivate 
personnel,  consolidate  functions,  and  refocus  attention  on  core  functions.  An  objective  of 
achieving  a  10  percent  or  $5  billion  reduction  in  administrative  cost  was  established." 
[Ref  2: p.  112] 

The  effects  of  the  DMR,  as  with  DAWIA,  with  regard  to  the  human  resources 
improvements  are  also  unclear.  Although  it  is  a  positive  step,  the  actual  results  of  any 
process  improvements  are  difficult  to  measure.  Its  focus  may  have  been  more  on  the 
outcome  than  on  the  process  itself 
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D.         LEGISLATIVE  IMPROVEMENTS 

In  exercising  its  power  of  the  sovereign,  the  Congress  enacts  various  laws  and 
rules  affecting  the  acquisition  system  and  its  process.  These  laws  are  normally  interpreted 
by  executive  agencies  and  promulgated  in  the  form  of  regulation.  Improvements  in  the 
acquisition  process  must  be  consistent  with  the  framework  that  the  Congress  establishes  or 
as  a  result  of  the  statute  enacted  by  Congress.  Over  the  years  Congress  normally  reacted 
to  real  or  perceived  problems  within  the  acquisition  process  by  passing  a  variety  of  new 
laws  including  the  Competition  in  Contracting  Act  (CICA)  and  the  Federal  Acquisition 
Streamlining  Act  (FAS A).  Both  of  these  have  had  an  effect  on  the  acquisition  planning 
process. 

1.         Competition  in  Contracting  Act  (CICA) 

According  to  Sherman,  the  Competition  in  Contracting  Act  "deserves  status  as  the 
keynote  for  government  procurement  processes  for  the  foreseeable  future."  Enacted  into 
law  as  Title  VII  of  the  Spending  and  Reduction  Act  of  1984,  CICA  set  the  stage  for  the 
micromanagement  of  government  procurement.  CICA  affected  virtually  all  the 
participants,  both  private  and  public,  involved  in  procurement  programs.  [Ref.  2: p.  79] 

Although  CICA  mandated  many  seemingly  broad  and  encompassing  changes  to  the 
procurement  process,  perhaps  its  most  significant  impact  was  the  congressional  urging 
that  Federal  agencies  do  a  better  job  of  planning  and  preparing  for  competitive 
procurements.  [Ref.  2:p.  81]  As  Nash  contends,  "Acquisition  planning  in  many  agencies 
has  historically  been  performed  in  a  sporadic  and  fragmented  manner.     Any  planning  that 
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occurred  was  often  informal  and  haphazard — often  dependent  on  the  personnel  involved." 
[Ref.  l:p.  9-10]  Through  CICA,  Congress  expressed  its  belief  that  procuring  activities 
"were  not  doing  the  kind  of  advanced  thinking  and  planning  necessary  to  achieve  an 
effective  and  efficient  procurement  process.  .  "  where  competition  was  believed  to  be  the 
key.  [Ref.  2:p.  81] 

The  CICA  requires  that  executive  agencies  "use  advance  procurement  planning  .  .  . 
in  preparing  for  the  procurement  of  property  or  services."  [Ref.  l:p.  10]  However,  neither 
CICA  nor  subsequent  legislation  defines  what  constitutes  an  advance  procurement  plan.1 
Federal  regulatory  bodies  such  as  the  Office  of  Federal  Procurement  Policy  (OFPP)  have 
promulgated  the  requirements  for  a  formal  acquisition  plan  in  the  FAR  (Part  7),  but  these 
only  spell  out  documentation  requirements.  Additionally,  Congress,  through  CICA,  urged 
Government  procurement  experts  to  find  ways  to  simplify  and  streamline  the  existing 
processes.  However,  CICA  itself  may  be  at  odds  with  this  declaration  in  that  it  includes  a 
significant  increase  in  administrative  requirements  as  well  as  new  procedural  rules.  [Ref. 
2:p.  82-83] 

2.         Federal  Acquisition  Streamlining  Act  (FASA) 

The  Federal  Acquisition  Streamlining  Act  of  1994  introduced  changes  described  as 
"sweeping"  and  "of  paramount  importance."  [Ref.  2:p.  93]  Signed  into  law  by  President 
Clinton  as  a  major  element  of  his  "Reinventing  Government"  initiative,  FASA  alters  or 


i 

It  should  be  noted  that  prior  to  CICA,  the  Armed  Services  Procurement  Regulation  (ASPR)  did  require  Advanced  Procurement  Planning,  but  the  extent  to  which  it 
was  used  is  not  known. 
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affects  some  225  provisions  of  law  affecting  the  procurement  process  in  Government. 
Based  on  the  work  of  the  Packard  Commission  of  1986  and  the  Section  800  Panel  Report 
chartered  by  Congress  in  1991,  FAS  A  introduces  legislative  changes  that  insert  practical, 
result  oriented  policies  into  the  acquisition  process.  [Ref.  2:p.  92] 

Among  the  more  significant  changes,  FASA  revised  the  traditional  definition  of 
what  constituted  commercial  products  or  items  in  an  attempt  to  exclude  these  from 
governmental  bureaucracies  and  regulations.  It  also  changed  the  Simplified  Acquisition 
Procedures  (SAP)  threshold  to  $100,000  from  $25,000  and  required  agencies  to  develop 
electronic  commerce  capabilities  in  order  to  retain  use  of  these  procedures  in  the  future. 
And,  it  established  $500,000  as  the  threshold  for  requiring  cost  and  pricing  data.  [Ref. 
20:p.  15-17] 

The  real  question  at  this  point  is  to  what  extent  will  FASA  improve  the  acquisition 
planning  process?  A  GAO  report  issued  in  1996  indicates  that  while  DoD  is  complying 
with  a  majority  of  FASA's  requirements,  many  civilian  agencies  may  not  be  complying 
with  the  act  as  originally  intended.  [Ref.  21  :p.  2-4] 

E.         INFORMATION  TECHNOLOGY  IMPROVEMENTS 

Sherman  states  that,  "[t]he  computerization  of  government  procurement  programs 
has  evolved  slowly."  He  goes  on  to  say  that  most  advances  in  the  automation  of  the 
acquisition  process  are  the  result  of  individual  effort  and  not  the  result  of  any  significant 
agency  initiatives.  From  a  policy  point  of  view,  more  effort  is  devoted  to  "procurement 
controls,  ethics,  policy,  and  audit  than  automation."     The  adoption  of  information 
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technology  by  the  government  does  not  match  the  progress  achieved  by  private  industry. 
[Ref.  2:p.  131] 

Within  many  corporations,  automated  purchasing  systems  are  integrated  with 
inventory,  demand  forecasting,  scheduling,  and  distribution  systems.  These  systems,  in 
most  cases,  far  exceed  what  is  available  at  most  government  organizations.  For  instance, 
at  Ford  Motor  Company,  IT  was  the  key  enabler  that  allowed  them  to  revamp  their  parts 
procurement  or  acquisition  process.  It  allowed  them  to  reduce  personnel  in  the 
purchasing  department  from  500  to  125.  This  quantum  leap  in  productivity  would  not  be 
possible  without  IT.  [Ref.  5:p.  41-44] 

1.         Information  Technology  in  Acquisition  Planning 

Within  the  Government  acquisition  environment,  there  seems  to  be  a  general 
paucity  of  data  concerning  the  use  of  IT  in  the  acquisition  planning  process.  This 
researcher  has  found  that  searches  of  automated  databases,  the  Internet  and  periodical 
literature  for  information  about  application  of  IT  to  the  Government  acquisition  process  in 
general  yields  little  information.  A  similar  search  conducted  on  commercial  systems  yields 
considerably  more  information. 

Explanation  for  this  occurrence  may  be  two-fold.  First,  there  is  a  tendency  in 
Governmental  organizations  to  develop  automated  procurement  systems  at  a  level  that 
benefits  top  management.  This  is  done  to  provide  upper  echelons  with  a  comprehensive 
management  information  system  used  in  its  oversight  function.  Secondly,  automated 
systems  within  Government  were  initially  developed  to  compile  statistical  data  as  a  means 
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of  proving  compliance  with  various  socio-economic  programs.  In  either  case,  the  impetus 
to  develop  automated  systems  within  the  Government  provided  a  different  initial 
motivation  from  that  of  the  private  corporations  which  have  most  always  been  driven  by  a 
desire  to  increase  productivity,  and  hence,  profitability.  [Ref.  2: p.  132] 

2.         Survey  of  Current  IT  System  Capabilities  and  Applications 

Only  recently  has  the  DoD  begun  to  realize  the  importance  of  IT  in  the  acquisition 
planning  process.  In  January  1995,  the  Under  Secretary  of  Defense  for  Acquisition  and 
Technology  (USD[A&T])  chartered  an  Automated  Acquisition  Information  (AAI) 
Process  Action  Team  (PAT)  to  "define  a  vision  and  build  a  roadmap  to  institutionalize  an 
automated  acquisition  information  process  to  provide  current  and  comprehensive 
information  ...  to  effectively  and  efficiently  buy  weapon  systems."  This  charter 
recognized  the  need  to  apply  IT  to  the  DoD  acquisition  processes,  but  what  was  decidedly 
unique  about  this  PAT  was  its  orientation  across  functional  areas.  For  the  first  time,  it 
recognized  the  need  to  integrate  program  management,  logistics,  engineering,  and  finance 
into  the  automation  of  the  acquisition  planning  process.  [Ref.  22:p.  26-27] 

Another  area  of  concern  recognized  by  the  AAI  PAT  was  the  lack  of  a  list  of 
automated  information  software  used  in  the  acquisition  process.  Individual  agencies  often 
develop  unique  software  in  support  of  their  particular  needs  when  information  systems 
may  already  exist  that  would  satisfy  that  requirement.  The  result  is  the  parallel  and 
duplicate  development  of  numerous  automated  acquisition  systems  within  the  Government 
acquisition  community.  To  correct  this  deficiency,  the  AAI  PAT  recommended  that  the 
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Naval  Air  Systems  Command  (NAVAIR)  PMA-250  collect  information  on  all  automated 
systems  used  in  the  acquisition  process.  [Ref.  22:  p  31] 

A  recent  review  (February  1997)  of  the  Defense  Acquisition  Deskbook  web  site  on 
the  Internet  confirmed  NAVAIR  PMA-250's  efforts  to  collect  this  data.  Under  a 
Software  Tool  Information  link,  there  was  a  listing  of  approximately  89  different 
acquisition  related  software  (Appendix  B).  This  is  consistent  with  a  1989  study  conducted 
by  the  Logistics  Management  Institute  that  identified  76  information  systems  supporting 
DoD  procurement  organizations.  [Ref.  23] 

The  PMA-250  list  includes  over  17  functional  areas  such  as  contract  management, 
program  management,  logistics,  test  and  evaluation,  engineering,  and  financial 
management.  Of  these,  there  were  approximately  49  systems  that  describe  contract 
management  as  one  of  the  functional  areas  supported  by  that  software.  Briefly,  53 
described  program  management,  30  logistics  and  37  financial  management. 

The  PMA-250  list,  however,  is  not  all  inclusive  and  may  only  include  DoD 
software.  A  search  of  the  Internet  for  acquisition  planning  tools  resulted  in  several  hits, 
both  commercial  and  private.  Of  these,  the  General  Services  Administration  (GSA)  Home 
Page  revealed  a  similar  undertaking  to  locate  and  canvas  agencies  for  software  used  in  the 
acquisition  planning  process.  For  example,  the  National  Aeronautics  and  Space 
Administration  (NASA)  listed  a  system  called  the  Acquisition  Planning  Expert  (APEX) 
that  reportedly  saved  over  six  million  dollars  in  five  years  of  use.  And,  GSA  reported  the 
use  of  a  system  called  Transmitting  Records  Electronically  and  Quickly  (TREK)  that 
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reduced  the  number  of  document  handoffs  from  49  to  4,  and  reduced  the  days  to  process  a 
purchase  request  from  36  to  14. 

3.         Planned  Improvements 

The  previously  reported  information  does  not  include  planned  improvements. 
Currently,  the  Defense  Logistics  Agency  is  undertaking  the  development  of  yet  another 
acquisition  related  software.  Known  as  the  Standard  Procurement  System  (SPS),  this 
system  is  intended  to  replace  legacy  systems  across  the  DoD  and  automate  still  existing 
manual  operations.  This  is  an  inherently  complex  task  given  that  DoD  procurement  is 
conducted  at  over  1500  contracting  offices  involving  approximately  56,000  individuals. 
[Ref.  23] 

The  Program  Baseline  Plan  describes  SPS  as  a  system  that  will  use  "commercial 
software  which  will  form  the  basis  for  an  automated  DoD  contracting  system  and  employ 
standard  data  and  data  transmissions  within  DoD  and  with  industry."  SPS  will  use  an 
open  systems  architecture  with  an  underlying  relational  database  and  will  be  Electronic 
Commerce/Electronic  Data  Interchange  (EC/EDI)  capable.  It  will  operate  on  a  stand- 
alone Personal  Computer  (PC),  in  a  network  environment,  or  in  a  "megacenter,"  and 
includes  hardware,  training,  maintenance,  and  deployment  services.  The  system  will  be 
capable  of  performing  the  full  range  of  acquisition  functions  including  procurement 
planning,  solicitation,  contract  award,  and  contract  administration.  The  estimated 
program  cost  is  approximately  $326  million  and  the  life  cycle  cost  through  the  year  2005 
is  $3,088  billion.  [Ref.  24] 
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One  of  the  key  goals  of  SPS  is  to  standardize  procurement  processes  within  the 
procurement  functional  area  of  the  DoD.  SPS  satisfies  this  goal  by  embedding  existing 
procurement  policies  and  procedures  into  a  single  automated  system  with  a  database 
shareable  by  other  DoD  users  and  then  replacing  existing  and  legacy  systems  throughout 
the  DoD.  By  linking  with  other  non-procurement  legacy  systems,  such  as  existing 
financial  systems  used  by  the  Defense  Finance  and  Accounting  Service  (DFAS),  SPS  will 
hopefully  ensure  quicker  and  more  accurate  contract  payments.  [Ref.  23 :p.  iii] 

F.         SUMMARY 

Efforts  at  improving  the  acquisition  process  have  not  produced  clear  and  easily 
discernible  results.  Organizational  changes,  such  as  the  recent  development  of  IPTs,  may 
have  only  allowed  acquiring  agencies  to  keep  up  with  rising  work  demands  caused  by  the 
increasing  complexity  of  weapon  systems.  Changes  to  personnel  requirements  and 
training  have  yet  to  produce  any  demonstrable  results  or  improvements  in  the  acquisition 
process.  Legislative  improvements  have  been  numerous,  and  in  some  cases  far  reaching, 
but  one  cannot  point  to  any  substantial  gain  in  productivity  as  a  result.  Various 
technological  improvements  to  the  acquisition  system  have  been  attempted,  but  again  with 
uncertain  or  marginal  success. 

Given  that  all  these  efforts  have  failed  to  produce  dramatic  improvements  in  the 
acquisition  process,  what  avenues  are  left  open?  Organizational  and  personnel  changes 
may  only  be  capable  of  producing  so  much  given  their  physical  limitations  and  finite 
abilities.    Legislative  changes  are  top  down  approaches  that  many  times  impose  more 
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requirements  than  they  eliminate,  consume  considerable  time,  and  produce  unpredictable 
outcomes. 

Information  technology,  though  often  seen  as  a  panacea,  has  also  failed  to  produce 
substantial  gains  in  productivity  within  Government.  However,  many  private 
corporations,  constrained  by  some  of  the  same  organizational  and  personnel  problems  as 
Government,  have  recently  used  IT  to  produce  phenomenal  improvements  to  their 
processes.  The  following  chapter  examines  the  role  of  information  technology  and 
suggest  ways  in  which  IT  could  be  used  for  leverage  to  produce  dramatic  gains  in 
productivity  in  the  acquisition  process. 
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IV.  THE  ROLE  OF  IT  IN  THE  ACQUISITION  PROCESS 

A.         INTRODUCTION 

The  Department  of  Defense  planned  to  spend  over  $9  billion  on  Information 
Technology  (IT)  and  related  services  in  1996,  over  a  third  of  the  total  Federal  IT  budget 
of  $26.5  billion.  This  does  not  include  an  estimated  $24  billion  to  $32  billion  that  DoD 
will  spend  for  software  embedded  in  major  weapon  systems.  [Ref.  25: p.  3,10]  But  since 
the  Office  of  Management  and  Budget  (OMB)  does  not  collect  comprehensive  budget 
data  on  IT  expenditures,  the  actual  amount  spent  on  IT  may  be  unknown.  Nor  do 
Government  agencies,  including  DoD,  break  out  IT  obligations  as  separate  line  items  in 
budget  submission.  [Ref.  25:p.  3-4]  However,  the  passage  of  the  Information  Technology 
Management  Reform  Act  (ITMRA)  may  have  some  future  effect  on  these  problems.  [Ref. 
26:p.  3] 

The  real  question,  however,  is  what  impact  has  this  voluminous  spending  had  on 
improving  Government  operations  or  processes?  Little,  if  any,  according  to  the  General 
Accounting  Office  (GAO).  GAO  states  repeatedly  that  these  information  systems  "cost 
millions  more  than  expected,  take  longer  to  compete  than  anticipated,  and  fail  to  produce 
significant  improvements  in  the  speed,  quality,  or  cost  of  federal  programs."  [Ref.  26:p.  2] 
"Despite  spending  more  than  $200  billion  on  information  management  and  systems  in  the 
last  12  years,  the  government  has  too  little  evidence  of  meaningful  returns."  [Ref  27: p  3] 
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The  GAO  is  not  alone  in  this  assessment.    The  Software  Technology  Support  Center 

(STSC)  states  that  [Ref.  28:p.  1-1]: 

The  software  industry  is  reaching  its  50  year  mark,  however,  the 
same  problems  that  plagued  us  20  years  ago  still  persist.  DoD  has  had  a 
distressing  history  of  procuring  elaborate,  high-tech  software-intensive 
weapons  that  do  not  work,  cannot  be  relied  upon,  modified,  or  maintained. 
Many  of  these  over  budget,  overdue  programs  have  been  canceled  after 
reaching  full-scale  production  with  millions  of  dollars  wasted,  and  not  a 
single  unit  reaching  the  warfighters'  hands.  With  virtually  every 
acquisition  snafu,  the  software  component  can  be  isolated  as  the  prime 
source  of  our  dilemmas. 

This  problem  is  not  unique  to  the  DoD  or  even  the  Federal  Government. 

Currently,   GAO   reports   that    11    federal   agencies   have   significant   problems   with 

information  management  systems  under  development  and  has  labeled  them  as  "high-risk." 

These  information  systems  are  defined  as  high-risk  "because  they  are  especially  vulnerable 

to  waste,  fraud,  abuse  and  mismanagement,  and  were  potentially  costing  the  government 

billions  of  dollars  without  clear  returns."  [Ref.  25:pl2]    The  systems  identified  are  key 

elements  of  mission  critical  components  that  together  represent  a  multibillion  dollar 

investment  of  scarce  Government  resources.  One  example,  DoD's  Corporate  Information 

Management  (CEVI)  initiative,  is  cited  as  consuming  over  $3  billion  annually  without 

demonstrating  any  real  benefit.  [Ref.  25: p.  12-14] 

B.         RECURING  FAILURES  IN  THE  ACQUISITION  OF  IT 

A  more  prominent,  and  consistent  theme  in  the  acquisition  of  IT  is  the  repeated 
failures  that  occur  over  time.  As  early  as  1979,  GAO  reported  that  of  the  custom  built 
Management  Information  Systems  (MIS)  under  development  for  governmental  agencies, 
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more  than  60%  had  schedule  overruns,  over  50%  had  cost  overruns,  more  than  45%  of 
the  software  could  not  be  used  for  its  intended  purpose,  and  29%  was  never  even 
delivered.  Normally  had  such  problems  been  publicly  scrutinized,  there  would  be  an 
intense  effort  to  correct  the  problem.  However,  over  the  next  15  years  the  problem  did 
not  go  away.  As  shown  in  Table  1  (adapted  from  the  STSC),  these  problems  continue 
through  to  the  present.  [Ref.  28:p.  1.3  -  1.6] 
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GAO  REPORT 

REPORT  FINDING 

Contracting  for  Computer  Software  Development:  serious 
Problems  Require  Management  Attention  to  Avoid  Wasting 
Additional  Millions 

November  9, 1979 

(FGMSD-80-4) 

Analysis  of  custom-built  MIS  systems  (163  contractors  and  113 
Government  personnel  surveyed)  produced  the  following  results: 

•  +60%  of  contracts  had  schedule  overruns 

•  +50%  of  contracts  had  cost  overruns 

•  +45  %  of  software  was  never  delivered 

•  +19%  of  software  had  to  be  reworked  to  be  used 

•  -3%  of  software  had  to  be  modified  to  be  used 

•  -2%  of  software  was  unusable  as  delivered 

Sergeant  York:  Concerns  About  the  Army's  Accelerated 
Acquisition  Strategy 

May  1986 
(GAO/NSIAD-86-89) 

•  64  (of  planned  614)  units  delivered  and  subsequently 
scrapped 

•  FOT&E  results  showed  significant  performance  shortfalls 

•  Cost  and  schedule  overruns  projected  if  government 
demanded  required  functionality 

•  $1.8  billion  lost 

•  Program  canceled 

Navy  Decision  to  Terminate  its  Standard  Automated  Financial 
System 

March  1989 
(GAO/IMTEC-89-37) 

•  $446.5  million  (99.. 9%)  projected  cost  overrun 

•  5  year  projected  schedule  overrun 

•  $230  million  lost 

•  Program  canceled 

Embedded  Computer  Systems:  Significant  Software  Problems 
on  C-17  Must  Be  Addressed 

May  1992 
(GAO/IMTEC-92-48) 

•  2  years  behind  schedule  (as  of  March  1992) 

•  $1.5  billion  cost  overrun 

•  Software  size/complexity  underestimated 

•  MilStds  waived  for  contractor  with  limited  software 
experience 

•  Shortcuts  taken  on  software  testing  and  software 
supportability  issues 

Software  Challenges  in  Mission  Critical  DoD  Systems 

December  24,  1992 
(GAO/IMTEC-93-13) 

1 5  major  systems  studied  had  the  following  common  problems: 

•  Poor  software  engineering  concepts,  methods,  and  practices 
used 

•  Proceeded  despite  serious  problems 

•  Requirements  were  ill-defined  and  unstable 

•  Architectures  were  inflexible 

•  Security  requirements  not  met 

•  Poor  testing  methods  and  procedures  used 

•  No  systems-level  integration  testing  performed 

Attach  Warning:  Status  of  the  Cheyenne  Mountain  Upgrade 
Program 

September  1994 
(GAO/AIMD-94-175) 

•  8  years  behind  schedule  (at  time  of  report) 

•  $792  million  over  budget  (at  time  of  report) 

•  11  years  projected  schedule  slip 

•  $896  million  projected  budget  overrun 

•  $22  million/year  additional  costs  for  continued 
operation/maintenance  of  old  system 

Comanche  Helicopter:  Testing  Needs  to  be  Completed  Prior 
to  Production  Decisions 

May  1995 
(GAO/NSIAD-95-1 57FS) 

•  Cost  tripled  in  10  years  (from  $12.1  million  in  1985  to  $34.4 
million  in  1995, 1 85%  cost  increase) 

•  Software  development  and  testing  problems 

•  Required  performance  has  been  decreased  by  74% 

Table  1  -  GAO  Reports  on  DoD  Software  Failures 
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In  all  fairness,  these  failures  in  the  acquisition  of  IT  are  not  strictly  a  DoD,  or  even 
a  Government,  problem.  A  study  conducted  by  IBM  of  24  leading  companies  that  were 
developing  large,  software  intensive  systems,  all  suffered  similar  problems.  Of  these 
commercial  and  state  government  entities,  55%  had  cost  overruns,  68%  had  schedule 
overruns  and  88%  had  to  be  redesigned  to  be  useable.  Similarly,  a  third  of  all  large-scale 
IT  programs  are  canceled  and  three  quarters  are  operational  failures.  Table  2  lists  some 
major  non-military  IT  acquisition  failures.  [Ref.  29: p.  88-89] 


Year 

Project 

Results 

1980s 

International  Telegraph  &  Telephone 
4  switching  systems 

•  40,000  function  point  system 

•  $500  million  lost 

•  Canceled 

1987 

California     Department     of    Motor 
Automated     Vehicle/Driver     License 
System 

•  3  (5,000  function  point  size) 

•  $30  million  lost 

•  Canceled 

1989 

State  of  Washington 

Automated  Social  Service  Caseworker 

System 

•  7  years  to  build 

•  Failed  to  meet  use  needs 

•  $20  million  lost 

•  Canceled 

1992 

American  Airlines 
Flight  Booking  System 

•  $165  million  lost 

•  Canceled 

Table  2  -  Major  Non-Military  Software  Acquisition  Failures 

The  preceding  discussion  may  lead  to  the  erroneous  belief  that  all  IT  acquisitions 

are  failures.  Several  programs,  including  both  Government  and  commercial,  are  IT 
success  stories.  These  include  the  IT  portions  of  the  Air  Force's  F-22  Advanced  Tactical 
Fighter  Program  and  the  Boeing  Corporation's  777  passenger  airplane.  Additionally, 
many  companies  successfully  implement  IT  in  their  companies  with  dramatic 
improvements  in  productivity  and  quality  standards.  [Ref.  28:p.  23-30]  The  real  question 
is —  what  defines  and  separates  these  organizations  from  others  that  failed? 
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C.         IT  TOOLS  AND  THE  ACQUISITION  PLANNING  PROCESS 

Over  the  last  12  years  the  Federal  Government  has  spent  over  $200  billion  on 

information  technology  trying  to  correct  efficiency  problems.  As  previously  discussed,  the 

results  are  disappointing  and  continue  to  this  day.    But  what  causes  this  failure  when 

government  tries  to  implement  information  technology  to  improve  its  processes?  Michael 

Hammer  provides  a  very  succinct  and  powerful  observation  about  how  IT  should  be 

applied:  [Ref  5:p.  83] 

A  company  that  cannot  change  the  way  it  thinks  about  information 
technology  cannot  reengineer.  A  company  that  equates  technology  with 
automation  cannot  reengineer.  A  company  that  looks  for  problems  first 
and  then  seeks  technology  solutions  for  them  cannot  reengineer. 

The  solution  within  an  organization  begins  with  first  understanding  the  capabilities 
of  information  technology.  This  understanding  need  not  be  in  depth  or  extreme,  but  rather 
a  generic  understanding  of  what  tools  a  particular  technology  or  application  brings  to  the 
process  table.  All  this  understanding  must  do  is  establish  a  connection  between  a  process 
objective  and  the  IT  tool  that  will  enable  its  accomplishment.  What  is  most  important  to 
remember  about  information  technology  is  that  it  is  a  "means  of  solving  business 
problems,  not  technologies  looking  for  uses."  [Ref.  30:p.  55] 

The  Federal  Government  may  now  just  be  realizing  this  lesson.  Recent  legislative 
efforts  including  the  Paperwork  Reduction  Act  and  the  Ginger-Cohen  Act  of  1996 
emphasize  the  meeting  of  agency  goals  through  the  effective  use  of  IT.  The  Ginger- 
Cohen  Act:  [Ref.  31:p.  9] 

[EJxplicitly  requires  agency  heads  to  analyze  the  mission  of  their 
organizations,  benchmark  and  assess  the  performance  of  their  business 
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processes  and,  based  on  this  analysis,  redesign  their  mission-related  and 
administrative  processes  (as  appropriate)  before  making  significant 
investments  in  information  technology  to  support  those  missions.  In  plain 
terms,  agencies  should  maximize  the  potential  of  technology  to  improve 
performance,  rather  than  simply  automating  inefficient  processes. 

The  real  influence  of  information  technology  on  the  acquisition  planning  process 
potentially  lies  in  its  "disruptive  power."  Leveraging  this  power  requires  that  long 
established,  traditional  rules  about  how  work  is  done  be  broken.  This  "breaking  of  the 
rules"  allows  individuals  to  begin  to  think  inductively  about  how  to  apply  technology 
during  the  reengineering  process.  Only  then  can  these  long  standing  work  rules,  on  which 
the  underlying  process  was  built,  be  changed  to  take  advantage  of  the  full  power  of  IT. 
Breaking  the  old  rules  creates  the  possibility  for  new  ways  of  working  and  with  that 
reengineering  can  begin.  [Ref.5:p.  91] 

Information  technology  is  the  essential  enabler  to  reengineering  because  it  allows 
business  processes  to  be  redesigned.  Merely  throwing  computers  and  software  at  an 
existing  process  does  not  constitute  reengineering.  Many  times  automation  only 
reinforces  old,  often  outdated,  ways  of  doing  business.  Nothing  new  was  created.  If  what 
was  being  done  was  wrong  in  the  past,  it  is  now  being  done  wrong  even  faster.  This, 
combined  with  the  inherent  complexity  of  the  existing  business  process,  is  a  certain  recipe 
for  failure.  In  fact,  the  misuse  of  technology  may  actually  block  any  anticipated 
improvements  in  performance  and  reinforce  old  ways  of  thinking  and  undesirable 
behavioral  patterns.  If  we  take  it  as  a  given  that  IT  is  misapplied  to  business  processes, 
then  how  is  this  corrected?  [Ref.  5:p.  83-84] 
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Hammer  provides  eight  key  examples  of  how  to  improve  business  processes  with 
technology.  Although  not  all  inclusive,  the  elements  in  these  examples  break  existing 
ways  of  looking  at  information  technology.  Some  examples  of  these  technologies  are: 

Shared  databases 

Expert  systems 

Telecommunications  networks 

Decision  support  tools 

Wireless  data  communications  and  portable  computers 

Interactive  video  disk 

Automatic  identification  and  tracking  technology 

High  performance  computing. 
None  of  these  technologies  are  new  or  startling.    But  if  used  correctly,  they  are  the 
enablers  that  foster  process  innovation.  It  is  the  critical  element  in  creating  a  new  way  of 
viewing  an  existing  process.  [Ref.  5: p.  92-99] 


1. 


Shared  Databases 


A  considerable  portion  of  modern  day  business  processes  are  a  reflection  of  pre- 
automation  paper  "shuffling"  techniques.  The  structure  of  many  business  processes  was 
originally  developed  around  the  file  folder.  Information  was  captured  on  paper  and 
distribution  limited  to  those  who  possessed  the  folder.  It  was  thought  that  copying 
machines  would  solve  this  problem  but  they  probably  exacerbated  it  by  creating  multiple 
copies  of  different  versions  of  the  same  file.  [Ref  5:  p.  92] 
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Another  result  is  that  many  business  processes  tend  to  be  structured  in  a  sequential 
nature.  Information  gets  passed  from  one  individual  to  the  next,  with  the  first  individual 
failing  to  see  what  later  edits  accomplished.  Information  technology  did  not  solve  this 
problem  for  most.  Word  processors  replaced  typewriters,  but  the  paper  trail  remained. 
The  implicit  rule  is  that  information  can  appear  in  only  one  place  at  one  time.  [Ref.5  :p. 
92] 

An  example  of  this  may  be  Navy  acquisition  plans.  The  Navy  Acquisition  Planning 
Guide  (APG)  specifies  that  "[t]he  AP  shall  be  limited  to  25  pages.  .  .  "  and  that  this  page 
limit  ".  .  .  is  to  be  exceeded  only  in  exceptional  cases."  The  approximately  100  or  more 
program  plans  (Appendix  C)  that  are  incorporated  into  the  AP  are  done  by  reference  only. 
These  additional  plans  are  maintained  apart  from  the  AP.  In  no  one  place  can  the  whole 
acquisition  plan  be  viewed.  [Ref.32] 

This  is  very  interesting  when  it  is  considered  that  the  APG  states  that  the  ".  .  .  AP 
defines  the  structure  of  the  program  throughout  its  acquisition  cycle."  It  also  states  that 
"[acquisition  planning  is  the  process  by  which  the  resources  and  efforts  of  key  personnel 
responsible  for  the  acquisition  are  coordinated  and  integrated  through  a  comprehensive 
plan  ..."  Given  this  preamble,  and  the  actual  makeup  of  the  plan,  it  is  questionable  if  the 
two  can  ever  be  reconciled  to  achieve  the  goal  of  ".  .  .  fulfilling  the  agency  need  in  an 
effective  and  timely  manner,  and  at  a  reasonable  cost."  [Ref.  32] 

However,  information  technology  could  potentially  change  this  approach.  Shared 
databases  allow  information  to  appear  in  as  many  places  as  it  is  needed,  simultaneously. 
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Any  number  of  people  can  share  this  information.  Acquisition  plans  need  not  incorporate, 
by  reference,  other  plans.  Nor  do  the  plans  have  to  be  subdivided.  The  database  itself 
may  now  become  the  plan.  Instead  of  the  process  being  fragmented  by  territorial  and 
inter-organizational  competition,  all  efforts  are  directed  at  the  same  goal,  maintaining  the 
acquisition  plan  as  it  was  originally  intended,  as  a  coordination  and  integration  tool. 

2.         Expert  Systems 

Expert  systems  use  business  rules  and  problem  solving  techniques  along  with 
databases  to  evaluate  situations  or  determine  courses  of  action.  These  systems  are 
designed  specifically  to  capture  and  apply  consistently  the  expertise  of  a  human  specialist 
in  a  particular  field.  Expert  systems  are  usually  very  powerful,  but  limited  in  their  scope  of 
application.  Examples  currently  in  use  are  medical  diagnosis,  manufacturing  quality 
control  and  financial  management.  [Ref  33: p.  494] 

Many  existing  information  systems  may  have  expert  systems  imbedded  in  them  as 
part  of  a  transaction  processing  system  or  it  may  be  as  simple  as  a  terminal  where  users 
query  the  system  for  answers.  At  the  heart  of  expert  systems  is  a  database  of  rules  called  a 
knowledge  base.  These  are  typically  a  set  of  instructions  stated  in  an  'TF-THEN"  format. 
For  example,  it  might  say;  If  the  price  is  under  $2,500,  then  check  to  see  if  a  credit  card 
was  used  to  buy  the  item.  [Ref.  33 :p.  494-495] 

Expert  systems  first  became  widely  available  in  the  1980's.  At  that  time,  most 
considered  them  primarily  as  a  means  of  replacing  costly  and  sophisticated  experts  with 
cheap  machines.  However,  that  reality  did  not  come  to  be.  What  did  transpire  was  that  it 
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allows  relatively  unskilled  employees  to  now  operate  at  nearly  the  level  of  the  highly 
trained  expert.  What  this  implies  is  that  one  generalist  supported  by  expert  systems  can 
potentially  do  the  work  of  many  specialists.  Now,  instead  of  having  several  individuals 
each  trained  to  do  a  specific  function,  one  individual,  called  a  case  worker,  can  accomplish 
all  the  functions. 

At  first,  this  may  not  seem  like  a  major  accomplishment,  but  consider  what 
happens  in  a  highly  sequential  administrative  process.  Previously,  each  worker 
accomplished  one  part  and  then  passed  it  to  the  next  person  to  accomplish  their  part.  Any 
one  who  has  dealt  with  a  bureaucracy  knows  that  each  step  adds  considerable  time  to  the 
process.  If  at  any  point  work  must  be  rerouted  back  in  the  chain,  it  becomes  even  longer. 
Each  handoffor  error  adds  even  more  time  to  the  process.  [Ref.5:p.  92] 

The  above  description  substantially  illustrates  the  acquisition  planning  process  for 
a  major  weapon  system.  Many  of  the  improvements  discussed  in  Chapter  III  alleviated 
some  of  the  delays  and  bureaucracies  associated  with  the  acquisition  process,  but  none 
have  dramatically  increased  the  productivity  of  the  process.  New  project  management 
organizations,  IPTs,  legislation,  and  numerous  other  efforts  have  been  attempted,  but  none 
as  of  yet  have  resulted  in  a  significant  improvement  in  procurement  lead  times.  Some  have 
made  coordination  easier,  provided  better  visibility  over  projects,  or  even  brought  better 
people  to  the  existing  process,  but  none  have  had  the  impact  that  the  application  of  expert 
systems  could  provide. 
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Expert  systems  have  the  potential  to  dramatically  reduce  the  time  element 
associated  with  acquisition  planning  by  eliminating  handoffs,  delays  and  errors  that  cause 
rework.  A  single  "case  worker"  could  manage  an  entire  acquisition  plan  backed  up  by  an 
expert  system  and  a  database.  This  case  worker  would  be  responsible  to  the  PM  for  the 
entire  acquisition  planning  process,  from  beginning  to  end.  Less  time  or  effort  would  be 
expended  on  passing  plans  back  and  forth,  going  to  endless  meetings,  and  doing  another 
iteration  of  a  plan  that  is  already  out  of  date. 

3.         Decision  Support  Tools 

A  technology  closely  related  to  expert  systems  is  Decision  Support  Systems 
(DSS).  Decision  support  systems,  like  expert  systems,  are  designed  to  assist  and  support 
the  user  in  the  decision  process,  except  the  DSS  is  used  in  situations  where  the  decision 
process  is  relatively  unstructured  and  only  part  of  the  information  needed  is  structured  in 
advance.  The  significance  of  the  DSS  is  that  it  allows  the  structuring  of  the  problem  by 
providing  needed  information,  much  like  advanced  help  programs  in  commercial  software 
programs.  The  difference  though  is  that  DSS  may,  because  of  the  nature  of  the  problems 
it  is  used  in,  require  the  system  to  retrieve  and  process  data  from  several  files  and 
databases.  It  may  also  use  information  provided  online  by  individual  decision  makers  in 
the  decision  process. 

Information  requested  from  a  DSS  are  not  presented  in  pre-formatted  reports. 
Instead,  each  query  generates  its  own  unique  output  in  a  format  determined  by  the 
recipients  at  the  time  of  need.    Typically,  queries  to  the  DSS  are  structured  as  questions 
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such  as,  "How  will  changing  the  requirement  from  400  aircraft  to  380  affect  the  overall 
price  of  the  program?"  As  can  be  seen  from  this  simple  question,  the  ability  to  query  the 
system  makes  it  possible  to  model  very  complex  problems  with  many  inter-related  issues. 
[Ref  33 :p.  487-488] 

One  of  the  appurtenances  of  the  industrial  age  in  modern  organization  is 
hierarchical  decision  making.  This  exists  because  workers  are  expected  to  do  only  one  job 
and  not  think  or  make  decisions  about  it.  All  decisions  are  referred  up  the  ladder  because 
managers,  with  their  broader  views,  are  the  only  ones  that  have  the  perspective  necessary 
to  make  informed  decisions.  However,  it  is  costly,  especially  within  Government,  to  retain 
decision  making  authority  at  higher  levels.  [Ref.  5:p.  95-96] 

In  a  memo  by  the  Under  Secretary  of  Defense  (Acquisition  and  Technology),  Dr. 
Paul  Kaminski  stated  that  "[u]nnecessary  layers  of  review  should  be  eliminated  and  the 
decision  making  authority  maintained  at  a  lower  level  more  familiar  with  the  details  of  the 
acquisition."  [Ref.  34]  This  statement  suggests  that  decisions  should  be  made  at  the 
lowest  level  consistent  with  regulation.  However,  the  empowerment  of  individuals  to 
make  decisions  cannot  be  achieved  only  by  conferring  the  authority  to  make  decisions.  It 
must  also  be  accompanied  with  the  information  necessary  to  make  those  decisions. 

Modern  DSS  combined  with  database  technology  can  provide  information 
previously  only  available  to  higher  level  managers.  Lower  level  personnel,  properly 
trained,  and  employing  easy  to  use  analysis  and  modeling  tools  can  make  sophisticated 
decisions  in  support  of  the  planning  process.  This  capability  allows  decision  making  to  be 
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retained  at  the  lowest  level  possible.  Decisions  are  made  much  quicker  and  are  resolved 
when  they  appear  in  the  process,  not  when  they  are  noticed  by  higher  management.  [Ref. 
5:p.  95-96] 

4.  Electronic  Commerce/Electronic  Data  Interchange  (EC/EDI) 

EC/EDI  is  a  form  of  electronic  communications  that  allows  trading  partners  to 
exchange  business  transactions,  such  as  purchase  orders,  in  a  form  that  can  be  readily 
processed  by  application  software.  Approximately  one  third  of  all  business  documents 
(invoices,  payments,  etc.)  are  transmitted  by  EC/EDI.  One  of  the  advantages  inherent  in 
EC/EDI  is  its  ability  to  reduce  the  time  needed  to  complete  business  transactions  and  to 
obtain  the  goods  and  services  an  organization  requires.  [Ref  33 :p.  372] 

Within  the  Government,  EC/EDI  is  becoming  increasingly  important.  FAS  A 
provided  an  incentive  for  all  procuring  agencies  to  start  using  EC/EDI  by  raising  the 
ceiling  for  purchases  allowed  under  small  purchase  rules  to  $100,000  from  $25,000. 
However,  FASA  provides  a  lower,  interim  threshold  of  $50,000  premised  on  whether 
agencies  can  verify  that  they  are  performing  75%  of  their  contracting  actions  using 
EC/EDI  methods.  [Ref.  39:p.  19] 

By  itself,  EC/EDI  may  contribute  little  to  improving  the  acquisition  planning 
process.  While  it  may  provide  more  opportunities  to  increase  efficiency  in  small  purchase 
scenarios,  in  larger  transactions  it  may  become  less  important.  It  may  still  prove  useful  in 
coordinating  acquisition  planning  over  geographically  dispersed  sites  and  in  the 
identification  of  potential  sources  of  supply.  However,  the  real  innovation  that  is  possible 
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with  EC/EDI  is  in  combining  it  with  other  process  changes  that  lead  up  to  the  electronic 
transaction.  [Ref.  30:p.  60-61] 

5.         Work  Flow  Systems 

A  relatively  new  appearance  in  information  technology  is  the  workflow  system. 
Workflow  systems  take  the  paper  forms  and  documents  an  organization  uses  in  its  day-to- 
day business  processes  and  automates  them  using  IT.  By  doing  this,  it  captures  the 
policies  and  procedures  of  the  business  into  electronic  forms  that  can  then  be  filled, 
processed,  authorized,  and  routed  by  various  workers.  Workflow  automates  the  flow  of 
information  within  the  business  or  organization.  [Ref.  35:p.  vii] 

Initially,  workflow  systems  were  developed  for  converting  paper  documents  to 
electronic  form  with  scanning  systems  and  then  either  storing  them  for  later  retrieval  or 
transmitting  them  electronically  with  rudimentary  e-mail  systems.  It  was  thought  this 
would  lead  to  a  "paperless"  environment.  What  actually  occurred  was  that  information 
generated  on  paper  often  exist  simultaneously  in  electronic  media,  leading  to  the 
proliferation  of  more  paper.  [Ref.  35  :p  214-215] 

The  new  generation  of  highly  sophisticated  workflow  systems  have  similar  goals, 
but  the  starting  point,  assumptions  and  impacts  are  entirely  different.  Early  workflow 
systems  attempted  to  automate  existing  paper-based  business  processes,  there  was  no 
attempt  to  review  the  underlying  process  itself.  Modern  day  workflow  still  has  some  of 
the  concerns  associated  with  imaging,  but  now  the  focus  is  on  redesigning  the  process 
before  implementing  workflow  systems.     Workflow  systems  are  tools  that  may  allow 
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reengineering  to  take  place,  but  it  is  not  an  inherent  solution  to  business  process  problems. 
Rather,  a  business  process  should  be  evaluated  and  workflow  technology  inserted  only  //it 
brings  about  the  desired  change  or  improvement  in  that  process.  [Ref.  35:p.  209] 

Within  the  acquisition  planning  process,  the  use  of  workflow  systems  is  not  clear. 
A  review  of  systems  being  used  indicates  that  some  packages  may  have  this  capability 
because  of  the  underlying  commercial  software  that  is  used.  For  instance,  the  Master 
Acquisition  Planning  Program  (MAPP)  may  have  workflow  capability  because  it  utilizes 
Microsoft  Word  as  the  underlying  software.  [Ref. 6]  Word  provides  a  basic  routing 
capability  that  when  combined  with  e-mail  allows  the  originator  to  control  the  process  that 
the  document  goes  through.  [Ref.  36:p.  329] 

Recent  literature  now  suggests  the  use  of  workflow  systems  as  a  means  of 
reengineering  a  part  of  the  acquisition  process,  specifically  the  development  of  Request  for 
Proposals  (RFP).  As  envisioned,  the  RFP  process  would  be  supported  by  a  workflow 
system  combined  with  a  shared  database.  There,  work  documents  would  be  indexed  and 
stored  for  retrieval  and  transmitted  using  an  electronic  communication  such  as  e-mail  to 
various  workers  involved  in  the  RFP  process.  [Ref.  3 7: p.  92] 

What  really  makes  this  a  robust  and  vital  workflow  scheme  is  its  definition  and 
control  over  the  RFP  process.  "[T]he  sequence  of  steps  and  agents  involved  in  a  process 
is  generally  enumerated  beforehand,  and  used  to  automatically  route  work  to  the  proper 
agent,  when  the  work  is  required  to  be  completed."  [Ref.  37:p.  92]  Additionally, 
templates  are  available  "that  describe  the  overall  flow  of  work  in  a  process,  along  with  on- 
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line  process  "help"  and  reference  information  (e.g.,  regulations,  contract  clauses,  etc.)." 
[Ref.  37:p.  92]  This  technology  is  readily  available  commercially  and  easily  adaptable  to 
Government  use.  However,  it  is  expensive  and  requires  an  investment  in  personnel 
training.  None  the  less,  the  decision  has  been  made  to  invest  in  this  technology  by  some 
Government  organizations.  [Ref.  3 7: p.  92-93] 

D.         SUMMARY 

The  Federal  Government's  investment  in  Information  Technology  is,  and  has  been, 
nothing  less  than  staggering  by  any  estimate.  The  yield  on  this  investment  is  questionable 
at  best.  Over  a  third  of  all  information  technology  projects  are  never  delivered.  Those 
that  are  delivered  will  likely  be  over  schedule  and  over  budget.  And,  of  those  that  are 
delivered,  many  are  unusable  for  their  intended  purposes  and  require  considerable  redesign 
to  be  useful. 

At  least  part  of  this  information  technology  crisis  may  be  a  result  of  how  agencies 
view  technology.  Many  see  IT  as  a  way  to  automate  existing  processes  and  never 
question  this  assumption.  Others  fail  to  recognize  the  solutions  that  IT  presents  or  to  take 
advantage  of  what  this  could  do  change  long  standing  administrative  processes. 
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V.  PATHOLOGIES  OF  THE  ACQUISITION  PLANNING  PROCESS 

A.  INTRODUCTION 

In  the  last  few  years,  there  has  been  an  increasing  demand  for  a  smaller 
Government  that  provides  improved  services  at  a  lower  cost.  Making  Government  more 
effective  and  efficient  has  become  a  national  issue.  [Ref.  26:p.  2]  Part  of  the  problem  is 
that  many  of  the  largest  Federal  agencies  "find  themselves  encumbered  with  structures  and 
processes,  aimed  at  the  demands  of  earlier  times,  and  designed  before  modern  information 
and  communications  technology  came  into  being."  [Ref.  38:p.  6]  If  this  is  true,  then  the 
current  acquisition  process  may  have  some  of  these  pervasive  and  systemic  problems,  or 
pathologies,  that  can  be  easily  identified. 

B.  PATHOLOGIES  IN  THE  ACQUISITON  PLANNING  PROCESS 

In  describing  opportunities  to  use  IT  during  process  innovation,  Davenport 
identifies  several  pathologies  that  are  present  in  existing  business  processes.  His 
discussion  is  premised  on  the  basis  that  before  a  process  is  redesigned,  it  must  be 
understood  what  effect  IT  can  have  on  the  process  and  where  this  effect  is  felt  the  most. 
In  other  words,  what  underlying  symptom  would  benefit  the  most  from  the  intelligent 
application  of  IT.  [Ref.  30:p.  50] 
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1.         Labor  and  Paper  Intensive  Activities 

Perhaps  one  of  the  more  recognized  benefits  of  automation  is  its  ability  to 
eliminate  or  reduce  human  labor.  Although  this  element  is  more  frequently  seen  with  the 
automation  of  manufacturing  processes,  it  is  also  associated  with  administrative  processes 
as  well.  However,  in  administrative  and  service  environments,  processes  are  frequently,  if 
not  routinely,  defined  by  the  existing  document  flow.  The  introduction  of  IT,  at  a 
minimum,  provides  the  opportunity  to  remove  the  paper  from  the  process  by  employing 
work  flow  tools  that  define  the  paths  an  electronic  document  takes  through  the  process. 
This  in  turn  may  significantly  reduce  the  need  for  some  human  labor  at  every  step  and 
increase  productivity.  [Ref  30:p.  51] 

Another  benefit  of  the  impact  of  IT  on  the  process  is  the  structure  it  lends  to  that 
process.  Regardless  of  whether  the  administrative  process  is  efficient  or  not,  it  is  now 
probable  that  automation  will  cause  it  to  be  done  the  same  way  every  time.  The  process  is 
now  better  defined  with  less  handoffs  and  passing  of  documents.    [Ref.  30: p.  51] 

Within  the  acquisition  process,  program  managers  are  facing  a  challenge  of 
maintaining  high  levels  of  service  to  customers  while  simultaneously  increasing  staff 
productivity.  As  previously  seen  in  Chapter  III,  ".  .  .  changes  to  the  acquisition  process 
alone  have  not  gone  far  enough  to  raise  staff  productivity.  Increasingly,  program 
managers  must  turn  to  technology  to  help  solve  the  problem."  [Ref.  39:p.  19] 

Even  acquisition  processes  that  are  currently  considered  well  managed  may  still  be 
too  labor  intensive  and  paper  based.    A  recent  study  of  the  Request  for  Proposal  (RFP) 
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process  by  Nissen  concluded  that  "the  baseline  RFP  process  represents  a  labor-intensive, 
linear  sequence  of  manual,  paper-based  activities  that  are  interspersed  between  numerous 
handoffs  and  reviews."  [Ref.  37:p.  91] 

2.  Capturing  Information 

Not  only  can  IT  reduce  or  eliminate  human  labor  from  a  process,  it  can  also 
augment  the  effort.  If  IT  is  exploited  to  capture  information  about  process  performance, 
then  that  information  can  be  analyzed  to  determine  what  improvements  or  changes  are 
required  to  optimize  performance.  This  analysis  can  be  done  by  individuals  involved  in 
managing  the  process  or  may  be  done  by  other  IT  tools  such  as  expert  or  decision  support 
systems.  [Ref.  30:p.  51] 

As  shown  in  previous  chapters,  many  procurement  organizations  seldom  use 
information  about  process  to  improve  productivity.  The  result  of  this  is  that  information, 
or  metrics,  critical  to  the  effective  operation  of  contracting  organizations  is  not  available. 
Generally,  these  organizations  rely  upon  "their  staffs  to  use  their  memories  to  handle  the 
next  acquisition  'just  like  they  did  the  last  one."  [Ref.  4:p.  378]  The  overall  effect  is  that 
management  and  acquisition  process  owners  may  lack  the  information  necessary  to 
improve  the  quality,  timeliness,  efficiency  and  effectiveness  of  their  operations.  [Ref.  4: p. 
378] 

At  NAVAIR,  a  review  of  AP  and  related  procurement  process  instructions  yields 
little  information  about  automated  systems  used  to  capture  information  about  the  process. 
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Mention  is  made  of  four  different  automated  systems  associated  with  the  procurement 
process  at  NAVAIR.  These  are  summarized  in  Table  3: 


System 

Description 

Acquisition 
Instruction 

PM  Information  System 
(PMIS) 

Management  Information  System 

NAVAIR  Acquisition 
Guide 

Program  Acquisition 
Information  System 
(PAID) 

Text  and  graphics  image  retrieval 
system  of  Navy/DoD  acquisition 
documents. 

NAVAIR  Acquisition 
Guide 

Acquisition  Tracking 
System  (ATS) 

Automated  database  of 
NAVAIR/PEO  ACAT  programs 
and  their  milestone  dates. 

NAVAIR  Acquisition 
Guide 

Acquisition  Document 
Processing  and  Tracking 
System  (Bar  Code 
System) 

Tracks  draft  APs  through  Phase  II 
review. 

Acquisition  Plans 
NAVAIRINST 

4200.36 

Table  3  -  AP  Related  Systems 

Of  interest  is  that  most,  if  not  all  of  these  systems,  capture  very  little  information  about  the 
structure  of  the  acquisition  process.  Information  is  collected  on  the  overall  time  a 
program  take  to  complete  (PMIS),  or  where  a  document  is  in  the  review  chain  (Bar  Code 
System),  but  none  appear  to  manage  or  help  direct  the  flow  of  the  process. 

3.  Sequential  Processes 

One  of  the  primary  benefits  of  defining  a  given  process  is  that  the  flow  can  better 
be  examined  for  opportunities  to  reduce  sequential  paths.  Within  predominately 
administrative  systems,  IT  can  significantly  reduce  cycle  time  and  substantially  increase 
productivity  by  allowing  some  previously  sequential  steps  to  be  performed  in  parallel.   It 
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also  makes  it  easier  to  identify  bottlenecks  created  by  sequential  work  flows  and  provides 
a  means  for  reconfiguring  around  these  bottlenecks.  [Ref.  30:p.  52] 

Since  "most  administrative  systems  are  characterized  by  a  mode  of  operation  in 
which  work  flows  in  a  serial  fashion.  .  . ,"  it  is  likely  that  many  acquisition  processes  suffer 
from  this  same  problem.  [Ref.  4: p.  378-379]  Given  this  understanding,  it  becomes  more 
clear  why  IT  often  does  not  produce  the  large  productivity  increases  that  were  originally 
anticipated.  Many  government  contracting  organizations  "attempt  productivity 
advancements  through  investments  in  technology  without  examining  the  basic  interoffice 
communications  processes.  Senior  leadership  is  left  questioning  the  value  of  new 
technology  following  marginal  increases  in  productivity.  If  the  'paper  process'  is  broken 
before  technology  insertion,  the  'paperless  process'  will  also  be  broken."  [Ref.  39:p.  22] 

4.         Analysis  of  Information 

As  previously  noted,  expert  systems  and  DSS  are  having  a  considerable  impact  on 
the  analysis  of  information.  IT  can  now  support  the  decision  making  process  in  ways  not 
widely  available  even  ten  years  ago.  Numerous  private  corporations  are  now  routinely 
using  expert  systems  to  make  decisions  ranging  from  whether  to  extend  credit  to  a 
customer  to  what  any  given  customer  should  pay  for  insurance.  Many  are  also  using  the 
power  of  these  systems  to  collect,  analyze  and  distribute  information  to  key  management 
personnel.  Many  are  reporting  that  managers'  understanding  of  the  business  are 
substantially  improved  and  a  dramatic  reduction  in  time  spent  on  routine  meetings.  [Ref. 
30:p.  52-53] 
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Based  on  the  information  in  Table  3,  it  appears  to  the  researcher  that  little  analysis 
is  done  by  any  expert  system  or  DSS.  Nowhere  in  the  relevant  instructions  does  it  discuss 
the  application  of  information  provided  by  such  an  automated  system.  Nor  does  it  instruct 
PMs  or  PEOs  to  collect  such  information  for  analysis  by  any  system.  [Refs.  46,47,48] 

5.         Database  Integration 

One  of  the  more  critical  aspects  of  IT  on  processes  is  its  ability  to  integrate 
information.  In  the  future,  it  may  become  increasingly  difficult  to  radically  improve 
process  performance  for  tasks  that  are  highly  segmented.  One  of  the  reasons  these  tasks 
remain  segmented  is  that  information  on  various  processes  are  stored  in  several  databases 
throughout  an  organization.  This  splitting  of  process  information  throughout  the 
organization  precludes  anything  but  incremental  improvements  in  processes  because  of  the 
complexity  of  dealing  with  all  those  databases.  Organizations  that  opt  for  more 
conservative  approaches,  that  are  incremental  in  nature,  may  find  themselves  increasingly 
behind  when  competing  with  others  who  have  achieved  radical  redesign  of  processes. 
[Ref.  30:p.  53-54] 

This  problem  of  integration  applies  to  the  acquisition  planning  process  as  well.  As 
shown  in  Table  3,  numerous  databases  are  used  just  in  the  AP  process.  And,  as  was 
previously  noted  in  Chapter  III,  over  80  types  of  acquisition  software  are  currently  in  use 
within  DoD.  In  fact,  several  of  these  may  be  in  use  in  the  same  office.  As  has  been 
observed,  "[t]he  typical  program  office  has  a  mixture  of  automation  technologies."  [Ref. 
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39:p.  20]     To  add  to  this  problem,  many  program  offices  may  not  have  established 
procedures  for  managing  all  of  these  IT  resources  effectively.  [Ref.  3  9:  p.  20] 

6.         Expert  Knowledge  of  Processes 

One  of  the  greatest  assets  of  any  organization  is  the  knowledge  and  experience  of 
the  people  who  make  up  that  organization.  However,  many  times  the  knowledge  and 
experience  these  personnel  possess  is  not  well  managed.  Part  of  the  reason  is  that 
common  wisdom  may  hold  that  knowledge  intensive  activities  are  not  viewed  as 
processes.  However,  a  number  of  private  corporations  are  capturing  this  knowledge  using 
IT  and  making  it  readily  available  to  the  rest  of  the  company.  The  goal  of  this  undertaking 
is  to  make  expert  knowledge  readily  available  to  the  entire  company.  [Ref.  30:p.  54] 

Within  DoD,  this  intellectual  vision  may  be  taking  shape.  The  Defense  Acquisition 
Deskbook  (DAD)  is  "an  automated  reference  tool  providing  the  full  complement  of 
acquisition  information  'at  the  fingertips'  of  the  acquisition  profession."  [Ref.  40:p.  40] 
The  DAD  provides  information  on  several  levels.  First  it  provides  current  mandatory 
DoD  regulations  that  must  be  followed.  Then  it  provides  discretionary  information  and 
guidance  where  mandatory  regulation  leaves  off.  It  also  provides  an  information  structure 
where  innovative  practices,  practical  advice  and  lessons  learned  can  be  reviewed.  Finally, 
it  will  stay  up-to-date  in  the  future  by  linking  directly  to  the  DAD  web  page.  [Ref.  40:p. 
40-42] 
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C.         SUMMARY 

The  business  processes  in  many  organizations  have  evolved  over  time.  Many  of 
these  broke  down  the  process  into  discrete  tasks  so  that  the  paperwork  aspects  could  be 
more  easily  managed.  The  introduction  of  rudimentary  IT  did  not  improve  performance, 
and  may  actually  have  hurt  it,  because  it  was  added  over  the  existing  paper  based  process. 

Within  the  acquisition  planning  process,  as  with  most  administrative  systems,  the 
file  folder  has  driven  the  development  of  many  processes.  The  result  is  that  most  of  the 
processes  tend  to  be  highly  sequential  in  nature  and  repetitious.  Information  must  be  sent 
through  the  sequence  over  and  over  again  for  all  individuals  to  have  a  chance  to  perform 
their  edit.  It  also  has  limited  the  size  and  complexity  of  documents.  Many  are  split  into 
several  individual  folders  or  files  when  in  reality  it  would  make  more  sense  to  combine  and 
integrate  them. 

Another  problem  has  been  the  inability  of  administrative  systems  to  capture  the 
knowledge  and  expertise  of  its  members,  to  help  them  make  decisions  about  it,  or  the 
sharing  of  this  information  with  other  administrative  systems.  Regulations  and  instructions 
attempt  to  do  this  but  are  only  as  good  as  the  human  memory.  Organization  innovations 
such  as  IPTs  and  matrix  organizations  may  have  only  helped  marginally.  Decision  making 
is  still  retained  at  higher  levels,  even  while  that  higher  level  exhorts  decisions  to  be  made 
at  the  lower  levels. 

Recent  developments  in  information  technology  over  the  last  several  years  added 
new  capabilities  that  need  to  be  revisited  with  respect  to  administrative  processes.   In  the 
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strictly  paper  environment,  information  was  limited  in  how  it  could  be  manually  distributed 
and  copied.  The  introduction  of  databases  allows  information  to  be  available  in  several 
places  at  the  same  time.  Expert  systems  and  decision  support  systems  change  the  way  in 
which  the  information  can  be  analyzed  and  decisions  made.  Workflow  packages  can 
overview  and  help  define  key  document  processes. 

These  changes  in  technology  require  that  the  acquisition  planning  process  must  be 
looked  at  anew.  What  previously  made  sense  from  an  organizational  point  of  view  may  no 
longer  work.  In  fact,  the  misapplication  of  these  technologies  may  prevent  the 
fundamental  changes  that  are  required  to  achieve  dramatic  improvements  in  the  acquisition 
planning  process. 

All  of  the  above  points  to  an  acquisition  planning  system  that  is  still  highly 
bureaucratic,  plagued  by  paper  and  still  highly  sequential  even  in  the  best  of  organizations. 
For  example,  the  Naval  Air  Systems  Command  (NAVAIR),  a  premier  contracting 
organization,  devotes  one  publication  of  well  over  300  pages  to  document  the  RFP 
process  as  it  currently  exists.  [Ref.  13:p.  i]  However,  an  extensive  review  by  the 
researcher  reveals  that  only  3  out  of  21  chapters  (26  of  300  plus  pages)  deal  even 
nominally  with  the  process.  The  vast  majority  of  this  publication  explains,  block  by  block, 
how  to  fill  out  all  of  the  paperwork  required  to  support  the  RFP. 

No  amount  of  training  on  this  publication  could  substantially  improve  the  RFP 
process.  No  matter  how  well  written  or  organized,  this  publication  could  not  materially 
affect  the  process  other  than  to  document  it  at  a  given  point  in  time.  To  achieve  order-of- 
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magnitude  improvements,  it  is  necessary  to  reengineer  this  process  using  information 
technology  as  the  essential  enabler. 
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VI.  REDESIGNING  THE  ACQUISITION  PLANNING  PROCESS 

A.         INTRODUCTION 

The  primary  goal  of  the  Department  of  Defense  is  maintaining  a  strong  national 
defense.  To  achieve  that  goal  the  DoD  must  maintain  a  strong  business  operation  that  is 
capable  of  effectively  and  efficiently  supporting  the  warfighter.  Acquisition  reform  is  a 
key  link  in  this  support  issue.  Placing  innovative  and  technologically  superior  weapons  in 
the  hands  of  that  warfighter,  within  an  austere  and  shrinking  Federal  budget,  will  be  an 
extremely  daunting  task. 

Accomplishing  this  task  will  require  new  approaches.  Dr.  William  Perry,  former 
Secretary  of  Defense,  in  a  memorandum  dated  14  September  1994,  remarked  that  "[t]he 
private  sector  has  found  that  attacking  business-process  cycle  times  is  a  powerful  weapon 
in  its  reengjneering  arsenal  which  generates  more  efficient  processes,  greater  product 
quality  and  improved  organizations  for  less  cost."  Dr.  Perry  was  convinced  that  focusing 
on  cycle  time  reductions  would  result  in  "substantial  gains  in  .  .  .  reducing  infrastructure, 
streamlining  and  improving  customer  service."  To  accomplish  this  reduction  in  cycle  time, 
Dr.  Perry  challenged  the  Military  Departments  to  reduce  cycle  time  "by  at  least  50  percent 
by  the  year  2000."  [Ref  41] 

But,  as  was  seen  in  Chapter  III,  various  attempts  to  improve  the  acquisition 
process  have  not  produced  substantial  or  definite  results.  These  resorts  to  "business  as 
usual"  may  not  prove  effective  in  the  developing  austere  fiscal  environment.    Nor  has 
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information  technology  alone,  as  described  in  Chapter  IV,  proven  to  be  the  "silver  bullet" 
needed  to  achieve  the  substantial  gains  in  productivity  currently  being  sought.  The 
pathologies  associated  with  the  acquisition  process,  as  presented  in  Chapter  V,  are  still 
prevalent  and  among  us. 

However,  if  we  are  still  intent  on  radically  improving  the  acquisition  process  (a 
50%  improvement  in  cycle  times  appears  to  be  radical),  then  we  must  attempt  new 
approaches.  It  is  the  point  of  this  paper  to  suggest  that  redesigning  the  acquisition 
planning  process  to  take  advantage  of  the  enabling  power  of  information  technology  is  at 
least  part  of  this  productivity  problem.  It  is  understood  that  IT,  in  and  of  itself,  cannot 
change  the  process  alone.  Other  human  and  organizational  factors  will  have  to  be 
considered.  But  an  understanding  of  the  existing  acquisition  process  may  suggest  avenues 
for  the  introduction  of  IT  into  that  process.  [Ref  30:p.  17] 

B.         DEFINING  THE  EXISTING  ACQUISITION  PLANNING  PROCESS 

Several  writers  on  Business  Process  Reengineering  (BPR)  have  expressed  the 
importance  of  understanding  existing  processes  before  designing  a  new  one.  [Ref  4,  5,  30, 
35]  Some  may  argue  that  the  essence  of  reengineering  is  starting  over  with  a  clean  sheet 
of  paper  so  as  not  to  be  hampered  by  preconceived  assumptions.  However,  Davenport 
provides  four  basic  reasons  for  defining  an  existing  process  before  designing  a  new  one. 
[Ref.  30:p.  137] 

First,  the  very  act  of  defining  the  process  serves  to  stimulate  understanding  and 
communication  among  the  participants  of  the  redesign.  It  provides  a  common  ground  that 
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all  can  agree  upon  as  a  starting  point.  This  can  become  particularly  important  when  the 
process  is  relatively  unstructured  or  when  individuals  find  it  difficult  to  even  view  their 
work  as  a  process.  Secondly,  in  most  complex  organizations,  such  as  the  DoD,  there  may 
be  simply  no  other  way  to  migrate  to  a  new  process  without  defining  and  understanding 
the  existing  process.  [Ref.  30:p.  137- 138] 

Third,  understanding  the  existing  problems  in  a  process  can  ensure  that  they  are 
not  repeated  in  the  redesign  process.  This  has  routinely  happened  with  the  automation  of 
an  existing  process  that  had  not  been  sufficiently  defined  (hence,  "paving  the  cowpaths"). 
Not  realizing  that  the  existing  process  is  highly  sequential  may  result  in  the  same  after 
redesign.  As  a  corollary,  endemic  problems  may  frequently  go  unnoticed  until  the  entire 
process  is  thoroughly  studied.  Defining  the  process  will  most  likely  identify  pathologies 
not  previously  understood  or  noticed.  [Ref.  30:p.  138] 

And,  most  critically,  understanding  and  defining  the  current  process  will  provide  a 
measure  against  which  the  redesigned  process  can  be  valued.  The  existing  process  allows 
the  collection  of  data  for  a  baseline  against  which  to  measure  the  redesign  objective.  For 
example,  in  the  acquisition  process  this  would  be  a  time  measure  of  the  Procurement 
Administrative  Lead  Time  (PALT)  before  and  after  redesign.  [Ref.  30:p.  138] 

1.         Federal  Acquisition  Processes 

To  begin  to  understand  the  existing  acquisition  planning  process  for  a  major 
weapon  system,  the  researcher  first  looked  at  the  guidance  provided  by  policy  or 
procedure.    The  Office  of  Management  and  Budget  (OMB)  Circular  A- 109  provides  the 
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basic  policy  to  be  followed  by  executive  branch  agencies  in  the  acquisition  of  a  major 
program.  In  setting  the  acquisition  policy,  it  only  defines  "the  rules  or  guidelines  that 
express  the  limits  within  which  action  should  occur."  [Ref.  42. p.  4]  OMB  does  not 
specify  any  process,  or  procedure,  for  the  acquisition  of  a  weapon  system;  it  only  sets 
broad  policy  requirement  within  which  agencies  must  act.  [Ref.  43] 

The  FAR,  at  Parts  7  and  34,  begins  many  of  its  discussions  on  acquisition  planning 
with  procedures2.  Part  34  "describes  acquisition  policies  and  procedures  [emphasis 
added]  for  use  in  acquiring  major  systems  consistent  with  OMB  Circular  No.  A- 109." 
Although  Part  34  directs  agencies  to  "establish  written  procedures"  for  the  acquisition  of 
major  weapon  systems,  it  does  little  in  the  way  of  actually  presenting  a  defined  process  for 
the  acquisition  of  those  system.  At  best,  it  is  a  policy  document  in  that  it  provides  limits 
within  which  program  managers  and  contracting  officers  should  act.  FAR  Part  34  also 
directs  the  program  manager  to  prepare  an  Acquisition  Plan  (AP)  in  accordance  with  Part 
7. 

The  acquisition  planning  as  defined  by  the  FAR  at  Part  7  is  a  "process  by  which  the 
efforts  of  all  personnel  responsible  for  an  acquisition  are  coordinated  and  integrated 
through  a  comprehensive  plan  for  fulfilling  the  agency  need  in  a  timely  manner  and  at  a 
reasonable  cost."    But  in  the  actual  delineating  of   procedure  (Section  7.104,  General 


2 
Before  going  any  farther  it  may  be  useful  to  differentiate  between  process  and  procedure.  The  American  Heritage  Dictionary  defines  a  process 

as  a  "series  of  actions,  changes,  or  functions  bringing  about  a  result."  It  similarly  defines  procedure  as  a  "series  of  steps  taken  to  accomplish  an 

end."  As  can  be  seen  from  the  definitions,  both  could  be  used  interchangeably.  For  the  purposes  of  this  research,  both  are  considered  essentially 

the  same,  differentiated  only  in  that  a  procedure  could  be  considered  a  part  of  a  larger  process. 
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Procedures),  it  only  states  three  actual  steps  a  planner  need  take;  1)  form  a  team,  2) 
consult  with  requirements  or  logistics  personnel,  3)  coordinate  and  secure  concurrence 
with  the  contracting  officer.  Other  than  that  it  does  not  provide  any  procedures  or 
processes  in  developing  a  plan.  What  it  does  provide  is  policy  guidance  on  the  content  of 
theAP. 

2.         DoD  Acquisition  Processes 

Within  the  DoD,  the  DoD  Directive  5000  series  provides  policy  and  procedures 
for  the  acquisition  of  major  weapon  systems.  The  March  15,  1996  update  broke  the  DoD 
5000  into  two  parts  while  "significantly  reducing]  the  length  and  complexity."  DoD 
Directive  5000.1  is  a  discretionary  document  specifically  directed  at  providing  "general 
principles  to  guide  all  defense  acquisition  programs."  As  such,  it  is  strictly  a  policy 
document  and  differs  from  the  DoD  Directive  5000.2R  which  "establishes  mandatory 
procedures"  for  major  weapon  system  programs. 

Part  1  of  the  DoD  5000.2R  provides  an  overall  acquisition  management  process 
for  the  DoD.  It  defines  in  broad,  overall  phases  the  process  a  weapon  system  would  take 
from  the  determination  of  a  need  through  the  disposal  of  the  system.  Follow  on  parts  of 
the  DoD  5000.2R,  though  entitled  Program  Definition,  Program  Structure,  and  Program 
Design,  provide  more  on  policy  issues  than  the  actual  process. 

However,  much  of  this  may  be  by  design.  The  DoD  5000. 1  enjoins  "Program 
Managers  and  other  participants  in  the  defense  acquisition  process"  to  turn  to  the  Defense 
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Acquisition  Deskbook  (DAD)  for  "assistance  in  implementing  guiding  principles  and 
mandatory  procedures." 

The  DAD  is  currently  managed  by  the  Joint  Program  Office  (JPO)  located  at 
Wright-Patterson  Air  Force  Base  in  Ohio.  The  DAD  is  a  two  part  automated  tool  of  DoD 
acquisition  information.  A  reference  library  contains  the  FAR,  DFARS  and  DoD  5000 
series  documents  along  with  every  supporting  document  or  statute.  The  information 
structure  contains  discretionary  guidance  accessed  via  the  topic  or  the  process.  [Ref.  40: p. 
41] 

The  process  portion  of  the  DAD  provides  information  on  the  actual  steps  in  the 
acquisition  process.  This  process  information  can  be  accessed  via  graphical  interface  in  a 
"point  and  click"  mode.  Information  on  the  process  flow  is  numbered  according  to  steps 
and  the  level  of  refinement.  For  example,  process  information  is  initially  broken  down  into 
four  steps  numbered  1.1  through  1.4  as  shown  in  Figure  1. 


1 
Process  Information 

. 

1.1 

Define  Needs  & 
Requirements 

1.2 

Plan  Acquisition  & 

Management  Strategies 

1.3 

Solicit  &  Award 

Contracts 

1.4 

Manage/Develop  Product 

and  Services 

Figure  1-  DAD  Acquisition  Process 
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Each  subsequent  block  can  then  be  broken  down  farther  to  define  the  process 
below  it.  Under  the  block  labeled  1.2  in  Figure  1,  Plan  Acquisition  and  Management 
Strategies,  several  more  blocks  then  define  the  next  steps.  The  following  steps  are  then 
laid  out  sequentially: 

1.2.1  Develop  Management  Strategy 

1.2.2  Develop  Acquisition  Strategy 

1 .2.3  Determine  Program  Baseline 

1.2.4  Establish  Risk  Management  Plan 

1.2.5  Document  Required  Program  Information 

1.2.6  Review  and  Approve  Plans  and  Resources 

After  this  point,  in  addition  to  being  sequential,  the  diagram  is  setup  so  that  every 
step  after  the  first  one  (1.2.1)  flows  into  every  step  after  it  (1.2.2,  1.2.3,  1.2.4,  etc.). 
Because  of  this  interconnection  between  every  step,  the  flowchart  loses  some  of  its  ability 
to  portray  the  actual  process  except  in  the  broadest  sense.  This  pattern  is  repeated  down 
to  three  or  four  levels  under  each  basic  step.  However,  it  is  still  very  much  a  macro 
overview  of  the  acquisition  process  and  does  not  substantially  define  the  acquisition 
planning  process.  [Ref.  44] 

3.         Naval  Air  Systems  Command  Acquisition  Processes 

The  Naval  Air  Systems  Command  (NAVAIR)  in  1993  managed  approximately 
17.3  billion  dollars  in  contracts  distributed  in  over  200  programs.  NAVAIR  employs  over 
47,000  military  and  civilian  personnel  and  is  currently  headquartered  in  Washington,  DC. 
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Additionally,  it  is  located  at  18  major  technology  and  engineering  centers,  test  and 
evaluation  facilities,  depots,  and  logistics  support  activities  nationwide.  Its  primary 
mission  is  to  deliver  and  support  aircraft  and  related  systems  which  can  be  operated, 
based,  and  sustained  at  sea.  Life  cycle  support  is  provided  for:  [Ref.  45] 

•  Carrier  and  other  air  capable  ship  based  aircraft  and  systems. 

•  Integrated  air  antisubmarine  warfare  and  antisurface  warfare  mission  systems. 

•  Marine  expeditionary  forces  aviation  systems. 

•  Maritime  air  launched  and  strike  weapons. 

•  Training  systems  for  aircrew  and  maintenance  personnel. 

The  acquisition  process  for  the  development,  production  and  support  of  these 

weapon  systems  is  extremely  complex  and  lengthy.    To  manage  this  process,  NAVAIR 

provides  its  program  managers  with  several  sources  of  guidance.      The  NAVAIR 

Acquisition  Guide  (AG)  is  designed  to  provide  "corporate  management  with  a  single 

consolidated  overview  of  the  major  internal  NAVAIR  acquisition  processes."  [Ref.  46:p. 

1]    As  such  it  attempts  to  consolidate  in  one  document  all  the  activities,  regulatory 

guidance,  and  documentation  requirements  needed  in  assisting  acquisition  managers  to 

plan  ahead.  It  is  felt  that  the  need  for  "program  managers,  particularly  new  managers,  to 

know  the  process  and  sequence  of  events  and  average  time  to  complete  events  is  essential 

for  planning  their  programs.  .  ."  [Ref.  46:  p.  1]   Additionally,  it  states  very  succinctly  the 

motivation  behind  this  focus  on  process: 

In  addition,  corporate  management,  by  seeing  the  entire  process, 
can  focus  on  better  ways  to  manage  that  process  by  minimizing  the 
number     of    program     reviews,     maximizing    parallel     vice     serial 
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documentation  reviews,  establishing  time  limits  for  each  part  of  the 
acquisition  process,  and  providing  a  feedback  system  for  performance 
measurement  against  established  time  standards. 

The  acquisition  process  at  NAVAIR  is  broken  down  into  several  subprocesses. 

These  processes  include: 

1 .  Program  Initiation  process. 

2.  Milestone  Review/ Approval  process. 

3 .  Program  Authorization  process. 

4.  Procurement  process. 

Of  these,  the  procurement  process  is  most  relevant  to  this  research  In  general,  it 
interfaces  the  program  initiation  process,  is  an  integral  part  of  the  Milestone 
Review/ Approval  process,  and  includes  the  program  authorization  process.  As  can  be 
seen  from  the  flow  chart  in  Appendix  D,  the  procurement  process  begins  with  the 
identification  of  a  requirement  and  generally  ends  with  the  release  of  a  solicitation.  Within 
the  procurement  process  is  the  development  of  the  Acquisition  Plan  (AP).  [Ref.  47: 
enclosure  (1)] 

The  NAVAIR  AG  defines  the  AP  as  the  "principal  document  for  in-depth  program 
planning,  review,  and  oversight."  [Ref.  46: p.  28]  In  support  of  this  requirement, 
NAVAIR  issued  a  separate  instruction,  NAVAIR  Instruction  4200.36  of  26  January  1994 
to  provide  guidance  on  the  preparation  of  APs.  As  shown  by  the  flow  chart  in  Appendix 
E,  it  also  provides  a  macro  overview  of  the  actual  process  necessary  for  the  preparation  of 
the  AP.  The  AP  process,  as  shown,  is  divided  into  two  major  phases.  [Ref.  48] 
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In  Phase  I,  the  PM  designates  an  AP  Action  Officer  and  an  AP  Preparation  Team 
that  will  prepare  the  draft  AP  for  review.  This  team  consists  of  a  minimum  of  eight 
personnel  from  most  of  the  functional  areas  within  the  NAVAIR  organization  such  as 
contracting,  engineering,  business-financial  management,  training  and  so  forth.  It  is  their 
responsibility  to  coordinate  the  input  for  each  section  of  the  AP  from  the  various 
functional  codes  within  NAVAIR.  Below  this  level,  the  process  is  not  broken  down 
further.  In  Phase  II,  the  completed  draft  AP  is  sent  back  out  for  extensive  review  by  a 
minimum  of  27  different  functional  areas  within  NAVAIR.  Again,  how  the  review  process 
flows  is  not  shown  in  the  literature.  However,  it  does  suggest  that  both  reviews  are 
conducted  by  individuals  who  then  return  their  comments  to  Action  Officer  who 
incorporates  comments  as  received.  [Ref.  48:p.  5-7,  enclosure  (5)] 

This  review  is  conducted  in  a  strictly  paper  mode.  Numerous  copies  are  dispersed 
throughout  the  organization  for  review  and  comment  as  required  by  instruction.  To 
control  the  flow  of  paper,  an  automated  bar  code  system  named  the  Acquisition  Document 
Processing  and  Tracking  System  (Bar  Code  System)  is  used.  This  system  provides 
"couriers  to  hand  deliver  draft  copies  of  unclassified  AP's  to  those  codes  required  to 
review  and  comment  .  .  .  plus  any  additional  codes  that  the  acquisition  manager  wants  to 
have  involved  in  the  AP  review."  [Ref.  48:p.  7] 

At  the  end  of  Phase  II,  comments  are  reviewed  and  resolved  by  the  PM.  In  some 
cases,  major  issues  may  surface  and  require  resolution  at  a  higher  level.    If  all  issues  are 
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resolved  at  the  PM  level,  the  AP  is  approved  and  signed  by  the  PM,  PCO,  Assistant 
Commander  for  Contracts,  and  the  Program  Executive  Officer  (PEO).  [Ref.  48:p.  7-8] 

The  time  frame  for  each  step  varies.  As  Table  4  shows,  the  development,  review 
and  approval  of  the  AP  requires  a  minimum  of  108  days  to  complete  and  can  go  to  greater 
than  163  days.  [Ref.  46:p.  28] 


Step 

Days 

Process 

1 

15 

PM  establishes  AP  Preparation  Team 

2 

45 

Team  develops  draft  AP 

3 

20-75+ 

Formal  review  process 

4 

5 

PM  resolves  review  comments  (PEO  Programs) 

5 

5 

APEO  reviews  for  format  and  policy  compliance 

6 

5 

PM  and  PCO  sign 

7 

5 

AIR-2.0  Signs  (Contracts) 

8 

8 

AIR- 1.0  (Plans  and  Policies)  or  PEO  approves  AP 

108-163+ 

Total  time  required  for  AP  process 

Table  4  -  AP  Process  Time  Table 

Given  that  APs  must  be  complete  before  contract  award,  this  process  could  potentially 
add  a  considerable  amount  of  time  to  the  acquisition  process.  When  the  average  time 
from  identification  of  a  requirement  to  contract  award  is  403  days  [Ref.  46: p.  3 2],  this  time 
of  108  days  or  greater  becomes  a  more  significant  part  of  the  entire  acquisition  process. 

Some  redesigns  of  the  process  have  been  initiated  by  NAVATR.  As  part  of  a 
Management  Plan  developed  by  the  Contracts  Competency  (AIR-2.0),  the  AP  process 
was  reviewed.  Changes  included  removal  of  the  requirement  for  strict  compliance  with 
the  AP  document  format,  only  requiring  that  it  meet  the  requirements  set  forth  in  the  FAR 
and  DFARS.  It  also  allows  PMs  to  use  other  program  documents  such  as  the  Acquisition 
Strategy  Document  (ASD)  to  fulfill  the  acquisition  planning  requirement.   It  also  removes 
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some  minor,  internal,   administrative  requirements.      However,  the  basic  process  is 
essentially  the  same.  [Ref.  49] 

C.        REDESIGNING  THE  ACQUISITION  PLANNING  PROCESS 

Given  the  above  definition  of  the  acquisition  planning  process  at  NAVAIR,  a 
number  of  questions  must  be  asked  and  answered  during  the  redesign  process.  If  it  is 
agreed  that  the  preparation  and  review  of  an  AP  is  a  highly  sequential,  paper  based,  people 
intensive  process,  then  what  IT  tools  could  be  brought  to  the  table  to  improve  the 
process?  Which  part  of  the  process  is  most  ripe  for  these  technological  improvements? 
And  finally,  should  the  redesign  be  innovative  and  completely  new,  or  an  improvement  to 
the  existing  process? 

First,  a  review  of  the  AP  process  shown  in  Table  4  and  Appendix  E  indicates  that 
Phase  I  and  Phase  II  of  the  process,  up  to  review  and  approval,  shows  that  most  of  the 
time  involved  in  the  development  of  the  AP  are  in  the  first  three  steps  (80  to  135  days). 
This  would  seem  to  be  a  productive  area  to  concentrate  redesign  efforts.  If  the  time 
required  for  these  three  steps  were  reduced  by  50%,  time  for  the  preparation  of  an  AP 
would  fall  to  68  to  95  days.  This  also  seems  like  a  productive  area  to  start  in  because  of 
the  considerable  paper  work  involved  and  the  high  level  of  human  labor  and  interaction 
(meetings,  conferences,  etc.)  required. 

As  stated  in  previous  chapters,  IT  can  provide  some  of  the  leverage  needed  to 
improve  processes.  Some  technology  is  currently  being  used  in  the  process.  Some,  such 
as  the  Bar  Code  System,  are  used  to  manually  track  paper  documents  through  the  review 
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process.  Word  processors  and  spreadsheets  are  no  doubt  used  throughout  the  process  as 
well.  Other  systems  are  alluded  to  such  as  the  Program  Acquisition  Information  Database 
(PAID).  PAID  is  a  text  and  graphic  retrieval  system  of  select  Navy  and  DoD  documents 
used  in  the  acquisition  process.  [Ref.  46: p.  2]  Some  systems,  such  as  the  Acquisition 
Tracking  System  (ATS),  are  used  to  track  weapon  systems  programs  and  their  respective 
milestone  dates.  [Ref.  46: p  21]  Still  others,  such  as  the  Program  Managers  Information 
System  (PMIS),  are  management  information  systems  used  to  provide  oversight  data. 
There  is  strikingly  little  information  in  the  AP  publications  and  instructions  on  any  other 
automated  system  used  in  this  process. 

What  IT  tools  could  be  used  in  the  AP  process?  Table  5  considers  the  key  IT 
tools  from  above  and  what  effect  each  potentially  could  have  on  the  AP  process.  Note 
that  a  considerable  amount  of  the  effect  is  the  potential  reduction  in  time.  Other  effects 
include: 

•  Reduction  in  management  oversight 

•  Improved  process  control  by  management 

•  Better  decision  making. 


Information  Technology 

Step 

Shared 
Database 

Expert 
System 

Decision 
Support 

Work  Flow 
Systems 

1 

Maintain  database 
of  available 
personnel  for  task; 
Team  exist 
"virtually." 
Effect:  Reduce  time. 

Suggest  personnel 
capabilities  needed  for 
particular  AP 
development. 

Effect:  Better  team 

None  suggested. 

None  suggested. 

2 

Database  becomes 
AP;  All  personnel 
involved  view  AP 

Evaluates  AP  under 
development; 
Reduce  number  of 

Provide  what  if 
scenarios  for 
management 

Define  AP  document 
flow;  provide  electronic 
document  control  and 
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simultaneously 
during  development 

Effect:  Reduce  time. 

people  involved  in 
AP;  eliminate 
handoffs;  Caseworker. 

Effect:  Better  AP. 

evaluation;  reduce  or 
eliminate  hierarchical 
decisior  making. 
Effect: i  ^tterDecision. 

routing;  readily 
available. 

Effect:  Control  Process 

3 

Allow  concurrent 

viewing  as  AP 

developed;  may 

eliminate  step  3 

entirely. 

Effect:  Reduce  time. 

Same  as  above,  may 
eliminate  step  3. 

Effect:  Reduce  time. 

Inject  management 
control  in  decision 
making  process. 

Effect:  Increased 
management  control. 

Same  as  above;  may 
eliminate  step  3. 

4 

Eliminate  or 
significantly  reduce 
step  4  to  1  day. 
Effect:  Reduce  time. 

Same  as  above,  may 
eliminate  step  4. 

Effect:  Reduce  time. 

Same  as  above;  may 
eliminate  step  4. 

Effect:  Reduce  time. 

Same  as  above,  may 
eliminate  step  4. 

Effect:  Reduce  time. 

5 

Eliminate  step  5. 
Effect:  Reduce  time. 

Eliminates  step  5. 
Effect:  Reduce  time. 

Eliminates  step  5. 
Effect:  Reduce  time. 

None  suggested. 

6 

Reduces  to  1  day. 

Reduce  to  1  day. 

None  suggested. 

None  suggested. 

7 

Reduce  or  eliminate. 

Reduce  or  eliminate. 

None  suggested. 

None  suggested. 

8 

Reduce  or  eliminate. 

None  suggested. 

None  suggested. 

None  suggested. 

Table  5  -  Effect  of  IT  on  AP  Process 

Given  this  information  on  IT,  what  would  the  redesigned  AP  process  now  look 
like?  The  estimates  summarized  in  Table  6  assume  that  a  shared  database  and  a  workflow 
system  are  implemented  to  redesign  the  current  process.  Expert  systems  and  decision 
support  systems  (DSS)  could  also  innovate  the  process,  but  in  order  to  keep  the  redesign 
simpler  and  based  on  current,  readily  available  technology,  these  technologies  are 
excluded  in  the  present  study.  Once  the  database  and  workflow  systems  have  been 
implemented,  it  may  be  prudent  to  reconsider  these  other  technologies.  This  will  also 
dramatize  the  point  that  the  correct  application  of  IT  can  have  considerably  more  effect 
than  the  application  that  has  traditionally  been  used  such  as  with  NAVAIR's  Bar  Code 
System  for  tracking  paper  shuffles  during  the  AP  process. 


Steps 

Days 

Process 

1 

1 

PM  establishes  AP  Preparation  Team 

2.0 

45 

Team  develops  draft  AP 
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2.1 

0 

Concurrent  formal  review  of  draft  as  developed 

2.2 

0 

Concurrent  PM  resolution  of  review  comments  as  raised 

2.3 

0 

Concurrent  APEO  review  for  format  and  policy  compliance 
Note:  step  may  be  eliminated  with  expert  system 

3.0 

1 

Concurrent  signatures  electronically 

47 

Total  time  required  for  AP  process 

Table  6  -  Redesigned  AP  Process 

In  the  first  step,  it  is  assumed  that  if  personnel  information  is  available  within  a 
combined  database,  15  days  would  no  longer  be  necessary  to  establish  the  team. 
Functional  area  managers  would  release  or  obligate  their  personnel  based  on  managed 
workloads  kept  in  the  shared  database.  In  the  second  step,  it  is  assumed  that  developing 
the  draft  would  occur  essentially  as  it  is  done  now.  What  is  different  is  that  because  of  the 
sharing  of  information  via  the  database,  approval  could  essentially  occur  as  the  AP  is 
written.  Reviewers  would  be  able  to  see  the  AP  as  team  members  are  drafting  it.  As  the 
reviewers  become  more  sophisticated  in  the  use  of  work  flow  systems,  the  process  time 
may  drop  further  as  the  process  itself  becomes  more  visible  to  the  participants. 

It  should  be  clear  from  this  redesign  that  we  are  not  just  simply  introducing  IT  into 
a  broken  process  (i.e.,  "paving  the  cowpaths").  Rather,  we  are  redesigning  the  process  for 
operation  in  an  IT  environment. 

D.         PROTOTYPING  AND  IMPLEMENTING  THE  REDESIGN 

The  previously  discussed  redesign  may,  or  may  not,  be  a  plausible  solution  to 
reducing  the  total  time  required  to  develop  an  AP.  A  radical  change  to  the  acquisition 
planning  process  based  solely  on  the  above  analysis  may  not  provide  an  acceptable  level  of 
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risk  for  most  managers.  A  way  to  mitigate  this  risk  would  be  through  the  development  of 
a  prototype.  Prototyping  is  an  acceptable  method  to  simulate  and  test  the  operation  of  a 
new  process  and  central  to  the  "re-invention  lab"  concept.  Davenport  defines  it  as  "an 
iterative  process  in  which  the  fit  between  new  process  structure,  information  technology, 
and  organization  is  refined  and  re-refined."  [Ref  30: p.  156]  It  is  analogous  of  a  scientific 
experiment  performed  to  validate  a  hypothesis. 

From  an  organizational  aspect,  it  would  be  a  small  scale  version  that  replicates  the 
intended  process  to  check  the  validity  of  the  design.  Given  the  nature  of  the  intended 
change  in  the  AP  process,  it  would  be  only  prudent  to  first  test  the  process  redesign.  This 
is  especially  important  because  of  the  sometimes  unintended  consequences  that  occur  with 
the  implementation  of  new  IT.  Also,  prototyping  is  essentially  a  learning  activity.  What 
was  constructed  on  paper  may  lack  a  certain  reality  when  implemented  in  person.  By 
prototyping,  lessons  can  be  learned  from  mistakes  in  a  controlled  environment.  Many 
iterations  may  be  required  to  perfect  a  redesign  in  this  manner.  [Ref.  30:p.  156-157] 

Perhaps  the  most  important  effect  to  consider  is  on  the  personnel  in  the 
organization.  In  more  than  one  occasion,  both  within  and  outside  of  government, 
organizations  have  mandated  the  implementation  of  a  new  system  without  a  consideration 
on  the  people  involved.  The  technology  may  have  been  flawless,  the  plan  superb,  but  the 
process  redesign  failed  to  provide  the  desired  results.  Much  of  this  is  a  failure  to  consider 
the  fit  of  technology  to  the  people  within  the  organization.  Destroying  or  disrupting  social 
interaction  by  confining  everyone  to  a  computer  cubicle  may  not  produced  the  desired 
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results  even  if  it  should  have  worked  on  paper.  Prototyping  may  overcome  this,  gradually 
reshaping  the  organizational  environment  or  allow  for  a  revising  of  the  technology 
involved.  [Ref  30:p.  156-157]  It  may  also  highlight  new  needs  in  terms  of  personnel 
skills,  education,  and  training  as  well  as  organizational  changes. 

E.         SUMMARY 

Radical  changes  are  needed  to  achieve  the  level  of  performance  that  will  be 
demanded  in  the  future.  Many  personnel  and  organizational  innovations  have  been  tried 
but  have  failed  to  achieve  large,  demonstrable  returns.  Process  improvements,  often 
ignored,  are  once  again  becoming  the  focal  point  for  decreasing  cycle  times  to  meet  new 
demands  on  Government  organizations. 

Redesigning  a  process  demands  an  in  depth  analysis  and  definition  of  that  process. 
This  is  a  learning  exercise  that  informs  and  communicates  much  about  the  process  under 
study.  It  is  a  necessary  part  of  the  redesign  effort  in  that  it  prevents  the  recurrence  of 
problems  that  reengineering  seeks  to  eliminate. 

Most  of  what  is  written  in  the  form  of  regulation  is  concerned  with  policy  over 
procedure  or  process.  This  sets  the  boundaries  within  which  agencies  must  act,  but  not 
how  they  accomplish  the  acquisition.  Only  recently,  via  the  automated  Defense 
Acquisition  Deskbook,  has  the  DoD  began  to  place  more  emphasis  on  the  process  and  not 
on  policy. 

The  acquisition  planning  process  at  NAVAIR  is  a  relatively  mature  and  well 
developed  process,  but  it  is  not  well  documented.    It  is  heavily  sequential,  paper  based, 
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and  personnel  intensive.  Little  effective  use  of  IT  has  been  implemented.  Systems 
currently  in  place  are  more  concerned  with  automating  existing  processes  than  using  them 
to  leverage  the  process.  Internal  redesign  efforts  focus  more  on  changing  the  existing 
process  through  eliminating  paper  requirements.  Overall  gains  from  these  efforts  were 
most  likely  marginal  at  best. 

The  redesign  described  above  considered  the  use  of  IT  to  dramatically  improve  the 
process.  To  mitigate  risk,  the  technology  used  was  limited  to  the  readily  available,  off  the 
shelf  variety.  Startling  new  technologies  will  not  necessarily  make  a  process  more 
effective  or  efficient.  In  many  cases,  lower  risk,  existing  technologies  with  a  proven  track 
record,  well  applied  in  the  design  of  a  process,  can  have  a  considerable  impact  on  the 
productivity  of  an  organization. 

At  NAVAIR,  as  with  many  other  Government  organizations,  technology  is  viewed 
in  a  completely  deductive  mode.  What  are  we  doing  now  that  could  be  done  faster  with 
technology?  This  approach  will  provide  some  improvements,  but  only  marginal  at  best.  A 
more  productive  line  of  reasoning  is  inductive;  how  can  the  process  be  redesigned  to  take 
advantage  of  technology's  power? 

NAVAIR,  as  may  be  representative  of  most  Government  organizations,  applied 
technology  to  track  where  the  location  is  of  a  piece  of  paper  in  a  manual  routing  process. 
It  treated  the  information  as  inventory  to  be  accounted  for  in  its  location.  At  best,  the  AP 
draft  is  accounted  for  now,  no  matter  where  it  is  located.  A  better  application  of 
technology  would  be  to  eliminate  the  paper  and  develop  a  common  database  combined 
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with  a  workflow  scheme  that  is  an  electronic,  or  "virtual"  plan.  This  requires  a  different 
way  of  viewing  the  process.  One  way  looks  at  it  as  a  process  that  is  broken  down  into  its 
smallest  parts.  The  other  way  looks  at  it  in  the  whole  for  a  solution. 
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VH.  RECOMMENDATIONS  AND  CONCLUSIONS 

A.  INTRODUCTION 

In  doing  this  thesis,  the  researcher  has  tried  to  avoid  the  overuse  of  terms  like 
reengineering,  Business  Process  Reengineering  (BPR),  re-invention,  acquisition  reform,  or 
any  number  of  other  terms  associated  with  these  very  recent  management  initiatives.  This 
was  done  to  avoid  connotations  similar  to  what  Total  Quality  Management  (TQM) 
inspires  in  some  minds.  However,  these  are  only  the  most  recent  in  a  spate  of 
management  techniques  spawned  over  the  years.  Management  by  objective,  operations 
research,  management  by  walking  around  (MBWA),  risk  assessment  and  financial  analysis 
all  fall  in  this  genre. 

Whatever  the  value  of  the  above  listed  techniques,  most,  if  not  all,  brought  some 
useful  element  or  tool  to  the  table  depending  on  the  time  and  the  place.  It  is  the  same  with 
BPR.  The  difference  in  this  case  is  that  Hammer  and  Champy  were  able  to  bring  attention 
to  BPR  at  a  time  when  its  potential  could  be  most  fully  realized —  when  the  maturity  of 
Information  Technology  (IT)  could  finally  start  to  have  a  substantial  impact  on  processes. 
But  the  "reinvention"  of  this  process  focus  is  an  idea  whose  time  has  come. 

B.  RECOMMENDATIONS 

The  following  recommendations  are  a  suggested  list  of  actions  that  many 
acquisition  organizations  could  take  to  reengineer  their  procurement  functions.  It  is  not 
proffered  as  a  cookbook  approach  to  making  reengineering  a  workable  solution.   Instead, 
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it  is  submitted  as  a  possible  course  of  action  that  could,  if  properly  applied,  significantly 
reduce  process  times  and  radically  improve  organizational  performance. 

1.         Identify  the  Process 

Acquisition  organizations  should  first  learn  to  correctly  identify  and  study  business 
processes.  Too  narrowly  or  widely  defining  a  process  reduces  the  likelihood  of  success. 
The  research  at  hand  investigated  the  acquisition  planning  process.  Going  to  a  higher 
level  than  this  would  have  meant  dealing  with  a  process  that  was  too  large  and  unwieldy. 
Any  smaller  and  the  benefits  may  begin  to  decrease.  Additionally,  the  opportunity  for 
introducing  IT  into  the  process  is  less  clear  at  either  end  of  the  extremes.  The  literature 
suggest  that  somewhere  between  10  and  20  key  processes  exist  within  any  organization. 
[Ref.  30:p.  28]  However,  based  on  the  researcher's  experience  and  observations,  many 
organizations  place  process  identification  at  the  lowest  priority. 

Throughout  the  research  effort,  there  was  strikingly  little  information  available  on 
organizations  that  had  studied  their  key  processes.  Only  three  articles  even  remotely 
spoke  to  process  analysis  within  organizations.  The  researcher  can  only  assume  that  this  is 
indicative  of  its  consideration  on  a  whole.  Some  progress  in  this  area  may  be  indicated. 
The  Defense  Acquisition  Deskbook  (DAD)  now  focuses  considerably  on  the  process 
initiative.  Some  management  literature  the  researcher  reviewed  from  the  Naval  Air 
Systems  Command  (NAVAIR)  showed  a  recent,  and  renewed,  interest  in  process 
definition  and  analysis. 
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2.  Additional  Technologies 

In  proposing  a  redesign  to  NAVAIR's  acquisition  planning  process,  the  researcher 
purposely  avoided  proposing  the  use  of  expert  systems  and  decision  support  systems 
(DSS).  The  reason,  in  addition  to  what  was  stated,  was  to  avoid  "assuming  solutions"  to 
problems.  The  use  of  readily  available  IT  made  the  solution  plausible  using  today's 
technology.  However,  expert  systems  and  DSS  are  both  mature  technologies  that  have 
been  around  for  a  number  of  years.  The  problem  with  inserting  these  technologies  is  that 
considerable  ground  work  must  be  done  to  develop  the  actual  human  knowledge  or 
wisdom  that  makes  them  viable.  However,  additional  future  gains  could  be  made  from 
these  technologies  if  started  now.  The  researcher  estimates  that  these  systems  could  be  in 
place  in  two  to  four  years  from  start  date. 

3.  Evolving  Processes 

As  seen  in  Chapter  IV,  many  of  the  IT  solutions  the  Government  undertakes  will 
most  likely  fail  or  cost  considerably  more  than  anticipated  while  not  producing  the 
productivity  enhancements  being  sought.  Of  the  many  reasons  previously  expressed  for 
this  failure,  it  is  the  researcher's  opinion  that  much  of  it  has  to  do  with  how  these  systems 
are  evolved.  Typically,  one  of  two  things  occur.  An  IT  system  is  bought  for  an 
organization,  or  group  of  organizations,  that  will  supposedly  solve  all  of  their  productivity 
problems.  An  example  of  this  would  be  the  various  purchasing  systems  such  as  SACONS, 
or  APADE.  The  other  end  of  the  spectrum  is  that  individual  offices  within  several 
organizations  will  develop  their  own  unique  solutions  to  IT  problems  (Appendix  B). 
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Neither  of  these  approaches  will  work  if  IT  is  to  be  successfully  applied  to  solve  process 

problems,  and  increase  productivity  substantially.  An  new  approach  must  be  developed. 

The  approach  suggested  by  the  researcher  is  to  identify  a  particular  program 

management  office  within  a  major  systems  command  as  a  test  laboratory.     Here  a 

redesigned  procurement  process  would  be  prototyped  using  IT  in  the  manner  described  in 

Chapter  VI.   A  comparable  or  similar  procurement  could  be  done  in  a  traditional  manner 

to  serve  as  a  benchmark  for  the  test  lab.   In  this  controlled  environment,  metrics  could  be 

easily  established  and  data  collected.     Subsequent  trials  could  be  used  to  refine,  or 

"tweek,"  the  system  to  achieve  the  greatest  process  improvement.   When  the  system  has 

proven  itself,  and  the  process  is  well  defined,  it  could  then  be  exported  to  similar  offices. 
If  it  subsequently  fails,  then  the  damage  has  been  contained  to  one  area  and  is  not  as 

intolerably  expensive  as  some  of  our  more  noticeable  IT  failures  today. 

C.    RECOMMENDED  AREAS  FOR  FUTURE  FOR  STUDY 

The  application  of  business  process  reengineering  to  acquisition  processes  is  an 
area  ripe  for  study.  Little  work  has  been  done  in  this  area,  but  it  will  undoubtedly  receive 
more  attention  in  the  future.  This  is  because  it  is  the  only  way  to  achieve  the  dramatic 
improvements  in  time  and  money  that  will  be  required  in  the  future.  As  pointed  out  in 
Chapter  III,  other  improvements  have  not  dramatically  improved  the  business  cycle  times 
or  cost  elements.  As  more  acquisition  professionals  realize  the  potency  of  reengineering 
principles,  increased  attention  will  be  focused  on  this  area. 

Some  recommendations  for  future  study  include: 
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1.  A  detailed  study  of  the  development  of  an  Acquisition  Plan  within  a  major 
systems  command. 

2.  The  relative  importance  of  various  IT  tools  in  reducing  cycle  times  within  a 
given  acquisition  area  or  process. 

3.  The  use  of  workflow  software  in  defining  acquisition  processes. 

4.  The  definition  of  all  the  major  processes  within  a  major  systems  command. 

D.        CONCLUSIONS 

It  has  been  the  researcher's  intent  to  wave  the  flag;  the  red  flag.  We  are  at  a 
critical  cusp  in  the  world  of  acquisition  reform.  Much  good  work  has  been  done  before  us 
by  a  long  line  of  acquisition  professionals  and  organizations.  However,  the  increases  in 
productivity  and  reductions  in  cycle  time  required  in  the  future  will  be  even  more  dramatic 
than  today.  In  the  near  term,  decisions  may  have  to  be  made  to  trade  off  acquisition 
overhead  for  warfighting  assets.  The  strategic  employment  of  information  technology  will 
make  these  decisions  much  more  bearable.  Accomplishing  a  reduction  in  cycle  times 
through  IT  will  also  allow  us  to  get  the  latest  technology  in  the  hands  of  those  warfighters 
even  sooner  than  we  already  do. 
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APPENDIX  A  -  WRITTEN  AP  ELEMENTS  (FAR  PART  7) 


(a)        Acquisition  background  and  objectives. 

( 1 )  Statement  of  need . 

(2)  Applicable  conditions. 

(i)         requirements  for  compatibility  with  existing  or  future  systems  or 

programs  and 

(ii)        any    known    cost,    schedule,    and    capability    or    performance 

constraints. 

Cost. 

(i)        Life-cycle  cost. 

(ii)        Design-to-cost. 

(iii)       Application  of  should-cost. 

Capability  or  performance. 

Delivery  or  performance-period  requirements 

Trade-offs 

Risks  (technical,  cost,  and  schedule) 

Acquisition  streamlining. 


(b) 


(3) 


4) 
5) 
6) 
7) 
8) 


Plan  of  action: 

1)  Sources. 

2)  Competition. 

3)  Source-selection  procedures. 

4)  Contracting  considerations. 

5)  Budgeting  and  funding. 

6)  Product  descriptions. 

7)  Priorities,  allocations,  and  allotments. 

8)  Contractor  versus  Government  performance. 

9)  Inherently  governmental  functions. 

1 0)  Management  information  requirements. 

11)  Make  or  buy. 

12)  Test  and  evaluation. 

13)  Logistics  considerations. 

14)  Government-furnished  property. 

15)  Government-furnished  information. 

16)  Environmental  and  energy  conservation  objectives. 

17)  Security  considerations. 

1 8)  Other  considerations. 

19)  Milestones  for  the  acquisition  cycle: 
Acquisition  plan  approval. 
Statement  of  work. 
Specifications. 
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Data  requirements. 

Completion  of  acquisition-package  preparation. 
Purchase  request. 
Issuance  of  synopsis. 
Issuance  of  solicitation. 

Evaluation  of  proposals,  audits,  and  field  reports. 
Beginning  and  completion  of  negotiations. 
Contract  preparation,  review,  and  clearance. 
Contract  award. 
(20)      Identification  of  participants  in  acquisition  plan  preparation. 
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APPENDIX  B  -  ACQUISITION  SOFTWARE  SURVEY 

As  of  21  February  1997 

Acquisition  Center's  Executive  System  (ACES  ) 

Acquisition  Professional  (AcqPro  1.6) 

Acquisition  Tracking  Tool  (ACQTRACK  1.0) 

AEGIS  Document  Imaging  System  (ADIS) 

Air  Force  Acquisition  Model  (AFAM) 

Air  Force  Medical  Acquisition  Model  (AFMAM) 

Analysis  Product  (Archer  1.0) 

Artillery  Systems  Analysis  Product  (Battleaxe  1 .0) 

ASC  Source  Selection  Application  (EZSource  1.1) 

Automated  CDRL  and  Tracking  System  (ACTS) 

Automated  Cost  Estimating  Integrated  Tools  (ACEIT  2.3) 

Automated  Data  Management  System  (ADMS  4.0) 

Automated  Information  Retrieval  System  (AIRS/PDM) 

Automated  Lesson  Learned  Capture  and  Retrieval  System  (ALLCARS) 

Automated  Test  Planning  System  (ATPS) 

Automation  of  Procurement  and  Accounting  Data  Entry  System  (APADE) 

Biweekly  Indicator  Tracking  System  (BITS  2.02) 

Budget/Readiness  Analysis  Technique  (BRAT  3.0) 

Commerce  Business  Daily- Synopsis  (CBD-Syn  v.  1 .7.2) 

Computer  Resources  Information  Base  (CRIB) 

Computer  Resources  Life  Cycle  Management  Plan  (CRLCMP) 

Computer.  Opt.  Mod.  Predicting/Analyzing  Support/Structure  (COMPASS  2.0a) 

Conformer  (Conformer  2. 1) 

Consolidation  Risk  Assessment  Methodology  (CORAM  3.2) 

Contract  Action  Tracking  System  (CATS  2.0) 

Contract  Appraisal  System  Module  (CAPPS  2.2) 

Contract  Data  Requirements  List  (CDRL) 

Contract  Monitoring  Automated  System  (CMAS  1 .2) 

Contracts  Information  Management  System  (CIMS  3.0) 

Correlation  Calculator  for  Cost-Risk  Analysis  (C-RISK  3.0) 

Cost  Analysis  Decision  Support  System  (CADSS  2.0) 

Data  Management  System  (DMS  5.25) 

Distributed  INFOSEC  Accounting  System  (DIAS) 

Early  Warning  System  (EWS  No  Ver  #) 

EDI  Watch!  (EDI  Watch  N/A) 

Electronic  Personnel  Security  Questionnaire  (EPSQ) 

Federal  Acquisition  Regulations  Automated  (FARA  6.0) 

Financial  Management  &  Execution  System  (FMETS  4.3) 
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Force  Cost  Model  (FCM  96.0) 

Formal  Risk  Analysis  (FRISK  3.2) 

Fuzzy  Logic  Applied  to  Risk  Evaluation  (FLARE  ) 

Helicopter  Analysis  Product  (Leonardo  1.0) 

Integrated  CDRL  and  Routing  System  (ICARS) 

Integrated  Management  Information  System  (EvflS  ) 

Joint  Advanced  Strike  Technology  Operating  and  Support  Technology  Evaluation  Model  (JOSTE 

1.0) 

Joint  Modeling  and  Simulation  System  (J-MASS) 

Joint  Services  Cost  Oriented  Resource  Estimating  (JCORE)  Model  (JCORE  1.42) 

LAN  Integration  and  Network  Kernal  (LINK  (TM)  1 .2) 

Litigation  Support  Data  Base  (LSDB  3.5.21) 

Logisitcs  Planning  and  Requirements  Systems  (LOGPARS  3.1) 

Louis  Link  and  Louis  H  (LOUIS  2.38) 

Maritime  Patrol  Aircraft  Analysis  Product  (Pegasus  1.1) 

Master  Acquisition  Program  Plan  (MAPP) 

Merged  Obligation  and  Liquidation  Tracking  System  (MOLTS  1.1) 

Military  Specifications  and  Standards  Data  Repository  (MILSPEC  1.1) 

Modernized  Parts  Control  Automated  Support  System  (MPCASS) 

Multi-User  Engineering  Change  Proposal  Automated  Review  System  (MEARS) 

Naval  Aviation  Lessons  Learned  (NALL  No  Vers  #) 

Operating  and  support  Management  Information  System  (OSMIS  FY95) 

Paragraph  Analyzer  (PARANA) 

Parametric  Cost  Estimating  Relationship  Module  (PACER  2.0) 

Parametric  Review  of  Information  for  Costing  and  Evaluation  (PRICE  PRICE  S  V2.ll,  PRICE 

H/HL/MV3.0) 

Performance  Analyzer  for  Windows  (PA  Win  1.2) 

Pre- Award  Information  Exchange  System  (PDCS  2.0) 

Process  Analysis  and  Project  Integrated  Environment-Integrated  Knowledge  Environment  (PAPIE- 

KE4.0) 

Procurement  and  Contracts  Tracking  System  (PACTS  6.5) 

Procurement  Contract  Monitoring  System  (ProCMAS  3.0) 

Procurement  Network  (PROCNET) 

Procurement  Request  Information  System  Module  (PRISM  6.4) 

Program  Acquisition  Management  System  (PAMS  1.12) 

Program  Integration  Scheduling  and  Management  System/ARDEC  (PRISM/ARDEC  3.0) 

Program  Management  Automated  Data  System  (PMADS  1.0) 

Program  Manager's  Workstation  (PMWS) 

Proposal  Evaluation  tool  (PET  1.1) 

Purchase  Request  Entry  Module  (PREM  6.4) 

Reliability  and  Maintainability  Logistics  (RAMLOG  No  Vers  #) 

Requisition  Automated  Processing  System  (RAPS) 

Resource  Analysis  Decision  Support  System  (RADSS  5.3) 
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RFP  Guidelines  (RFPGUIDE5) 

Satellite  Communications  Management  Information  System  (SCMIS  3.1) 

Security  Information  Management  System  (SEMS) 

Security  Management  System  (SecurTrac  1.0) 

Shared  Program  Information  Network  (SPINE  ) 

Software  Specification  Assistant  (SSA  3.4) 

Specification  Trainer-Editor  (SpecTrE) 

Supply  Automated  Management  System  (SAMS) 

System  Evaluation  and  Estimation  of  Resources  (SEER) 

Team  Work  Plan  (TWP) 

Turbo  Streamliner  (TURBO  1.0) 
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APPENDIX  C  -  PLANS  SUBSUMED  BY  THE  MAPP 


Source:  NAVSEA  Master  Acquisition  Planning  Program  Handbook 


1.  Acquisition  Plan 

2.  Computer  Resources  Integrated  Support 

3.  Computer  Resources  Life-Cycle 
Management  Plan 

4.  Configuration  Audit  Plan 

5.  Configuration  Plan 

6.  Continuous  Acquisition  and  Life-Cycle 
Support  (CALS)  Implementation  Plan 

7.  Depot  Planning  Annex 

8.  Electromagnetic  Compatibility  Program  Plan 

9.  Electromagnetic  Interference  Control  Plan 

10.  Electrostatic  Discharge  Control  Program  Plan 

1 1 .  Engineering  Change  Proposal  System  Safety 
Report 

12.  Engineering  Data  Management  Plan 

13.  Equipment  Facilities  Requirements  Plan 

14.  Facilities  Requirements  Plan 

15.  Facilities  Requirements  Report 

16.  Failure  Modes  Effects  and  Criticality  Plan 

17.  Government  Concept  of  Operation  (CALS) 

18.  Hardness  Assurance,  Maintenance,  and 
Surveillance  Plans 

19.  Hardness  Surveillance  Plan 

20.  Human  Engineering  Dynamic  Simulation 
Plan 

21.  Human  Engineering  Program  Plan 

22.  Human  Systems  Integration  Plan 

23.  Implementation  Plan 

24.  Integrated  Logistic  Support  Plan 

25.  Integrated  Support  Plan 

26.  Interface  Requirements  Specification 

27.  Interim  Contractor  Supply  Support 
Management  Plan  Report 

28.  Interim  Contractor  Support  Plan 

29.  Interim  Support  Plan 

30.  Level  of  Repair  Program  Plan 

31.  Logistic  Support  Analysis  Plan 

32.  Logistics  Requirements  Funding  Summary 

33.  Logistics  Support  Analysis  Plan 

34.  Logistics  Support  Analysis  Use  Study 

35.  Maintenance  Plan 

36.  Manpower,  Personnel,  and  Training  (MPT) 
Concept  Document 

37.  Military  Characteristics  Document 

38.  MPT  Resources  Requirements  Document 


39.  Navy  Training  Plan 

40.  Nuclear  Hardness  and  Survivability  Program 
Plan 

41.  Nuclear,  Biological,  and  Chemical 
Contamination  Survivability  Assurance  Plan 

42.  Operation  Requirements  Document 

43.  Operations  Support  Plan 

44.  Packaging  Management  Plan 

45.  Packaging,  Handling,  Storage,  and 
Transportation  Program  Plan 

46.  Phased  Support  Plan 

47.  Post  Production  Support  Plan 

48.  Program  Protection  Implementation  Plan 

49.  Quality  Assurance  Program  Plan 

50.  Radar  Spectrum  Management  Control  Plan 

51.  Real-Time  Outfitting  Management 
Information  Systems  Management  Plan 

52.  Reliability  and  Maintainability  Program  Plan 

53.  Risk  Management  Plan 

54.  Safety  Studies  Plan 

55.  Site  Evaluation  Report 

56.  Software  Development  Plan 

57.  Software  Quality  Program  Plan 

58.  Software  Support  Transition  Plan 

59.  Standardization  Accomplishment  Report 

60.  Standardization  Program  Plan 

6 1 .  Supply  Support  Management  Plan 

62.  Support  Site  Activation  Plan 

63.  Supportability  Assessment  Plan 

64.  System  Safety  Hazard  Analysis  Report 

65.  System  Safety  Program  Plan 

66.  Technical  Data  Acquisition  Plan 

67.  Technical  Data  Management  Plan 

68.  Technical  Manual  Organization  Plan 

69.  Technical  Manual  Plan 

70.  Technical  Manual  Publication  Plan 

71.  Technical  Manual  Quality  Assurance 
Program  Plan 

72.  Technical  Manual  Schedules  and  Status 
Report 

73.  Technical  Manual  Validation  Plan 

74.  Technical  Manual  Verification  Plan 

75.  Test  and  Evaluation  Master  Plan 

76.  Test  and  Evaluation  Program  Plan 

77.  Testability  Program  Plan 
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78.  Training  Device  Requirements  Document 

79.  Training  Effectiveness  Evaluation  Plan 

80.  Training  Equipment  Requirements  Document 

81.  Training  Facilities  Report 

82.  Training  Systems  Alternative  Report 

83.  Transition  Plan 

84.  Transportation  Plan 


85.  User's  Logistics  Support  Summary 

86.  Verification,  Demonstration,  and  Evaluation 
Plan 

87.  Version  Description  Document 

88.  Waiver  or  Deviation  Safety  Report 

89.  Weapon  System  and  Equipment  Transition 
Plan 


Note:  Plans  in  bold  type  are  required  by  DoD/DoN  5000  series  instructions. 

Note:   Many  of  the  incorporated  plans  have  duplicate  titles.   The  total  number  of  plans  subsumed  in  the 

current  version  of  MAPP  is  101. 
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APPENDIX  D  -NAVAIR  PROCUREMENT  PROCESS 


BRIEF  OVERVIEW  OF 

PROCUREMENT  PROCESS 

FOR  A 

MAJOR  SOLICITATION 


Program  Manager  (PM) 
Identifies  Requirement 


PM  Outlines  Schedule, 

Related  Procurements, 

Obtains  Procurement  Number, 

and  Enters  Data  into  PMIS 


I 


PM  Defines 

Procurement  Team 


PM  /  AIR-OS  /  AIR-04  /  AIR-02 

•Statement  of  Work  (SOW) 

•Specifications 

•System  Security  Engineering 

Implications  for  SOW  /  Specs 

(see  AIR-546  &  07T3 
•Sections  B-H,  J 
•Contract  Data  Requirements  List 

(CDRL) 
•DD254  (Cog  Engineer  may  require 

AIR  07T3  Assistance 
•Cost  Analysis  Requirements 
•Acquisition  Plan  Inputs 
•Tech  Data  (manuals  &  drawings 


PM  Issues 
Requirements  Letter 

i 


PM  Convenes  PPC  to 
Discuss  Strategy/Issues 


PM  Issues  PPA  w/Updates 

as  needed  to  show 

Prog/Mission  Changes 

and  maintains  PMIS  data 


PM  /  AIR-02  /  AIR-OOC 

•Synopsis 

•J&A 

•Sections  H  -  M 

•Legal  Review 

•Acquisition  Plan  inputs 


ALL  MEMBERS  OF  TEAM 
•When  applicable,  prepare  source 
selection  plan,  and  Sections  K.L.M 
•Draft  Contract  Line  Item  structure 


Develop  Sub-Team 
Structure  &  Assignments 
A 


NO 

e.g., 

Small  procurement 

Few  personnel  on  team 

Specifications  are  complete 


Complex  procurement 
Large  team  composition 
Considerable  matrix 
involvement 


Sub-Teams  &PM  Review  Draft 

Solicitations,  Perform  DRRB 

Function  &  Sign  CDRLs 


Procurement  Team  Prepares 
Draft  Solicitation  in  Group 

Sessions  &  Performs  DRRB 
Function  and  Sign  CDRLs 


J 


AIR-08  Review  SOW 

to  Validate  Proper  use 

of  Funding  Type 


i. 


PCO 
Issues  Synopsis 


Syrj 

I 


PM  or  Designee  Routes  Draft 

Solicitation  to  AIR-07T3  & 

AIR-7133  for  Tech  Security, 

Acq  Protection,  &  A  IS  Review 


Team  issues  Draft  Solicitation 

to  Industry  for  comments  & 

AIR-02  issues  draft  document 


Team: 

a)  Reviews  Comments 

b)  Responds  to  All  Comments 
via  PCO 

c)  Incorporates  Applicable 
Changes  to  Draft  Solicitation 


I 


e.g., 

Major  competition 
Ample  obligation  time 
Many  unknowns  in  specs 
Need  streamlining  assistance 
Questions  on  vendor  base 


Proc  Team  Review  Final  Solicitation 
&  Obtains  Signature  on  Cover  Page 


T 

Solicitation  Release  *    | 


NO 


e.g., 

Insufficient  Time 
Well  defined  specs 
Follow  on  buy 


1  Note:  For  competitive  NAVAIRHQ 
solicitations,  SSA  approval 
is  required. 
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APPENDIX  E  -  NAVAIR  AP  PROCESS 


PEO  (A)  and  PEO(T)  ACQUISITION  PLAN 
PREPARATION  AND  APPROVAL  PROCESS 


PHASE 


PM  DESIGNATES 
AP  ACTION  OFFICER 


TIGER  TEAM  ESTABLISHED 
TO  DRAFT  AP  (ACTION 
OFFICERS,  PCO,  BFM,  APML 
ANDAPM(S/E))  +  AIR-5112 


DRAFT  AP  PREPARED 
FOR  REVIEWS 


PHASE  II 


DISTRIBUTION  TO  KEY 
PERSONNEL  FOR 
REVIEW/COMMENT* 


ACTION  OFFICER 

INCORPORATES 

COMMENTS 


REVIEW  AND 
APPROVAL 


APEO  (ACQ)  REVIEWS 
AP  FOR  FORMAT  AND 
POLICY  COMPLIANCE 


ACTION  OFFICER 

INCORPORATES 

COMMENTS 


AP  TO  DPEO  FOR 
CONCURRENCE 


APEO  (ACQ)  FILE  AND 
DISTRIBUTE 
APPROVED  AP 


\ 


99 


100 


LIST  OF  REFERENCES 

1.  Nash,  R.  C,  and  Cibinic,  J.,  Competitive  Negotiations:  The  Source  Selection  Process, 
The  George  Washington  University,  1993. 

2.  Sherman,  S.  N.,  Government  Procurement  Management:  Special  Edition, 
Woodcrafters  Publications,  1995. 

3.  Department  of  Defense  Regulation  5000.2-R,  March  15,  1996. 

4.  Kestenbaum,  Martin  I.,  Hooker,  W.  J.,  and  Straight,  R.  L.,  From  Budget  to  Award: 
Acquisition  Process  Flow  Analysis,  Proceedings,  1993  Acquisition  Research 
Symposium. 

5.  Hammer,  M,  and  Champy,  J.,  Reengineering  the  Corporation:  A  Manifesto  for 
Business  Revolution,  Harper  Business,  1994. 

6.  Master  Acquisition  Program  Plan  (MAPP)  User's  Handbook. 

7.  Ferrara,  Joe,  DoD  'S  5000  Documents:  Evolution  and  Change  in  Defense  Acquisition 
Policy,  Acquisition  Review  Quarterly,  Fall  1996. 

8.  Zsak,  Mike,  DoD  Policies  &  Procedures,  Addressing  Risk  Management,  Defense 
Acquisition  Deskbook,  Version  1.3,  31  December  1996. 

9.  Glotfelty,  Barbara,  Acquisition  Strategies  Vs.  Acquisition  Plans,  Defense  Acquisition 
Deskbook,  Version  1.3,  31  December  1996. 


101 


10.  McMahon,  Paul  T.,  and  McDaniel,  Norman  A.,  Acquisition  Strategy  Guide,  Second 
Edition,  Defense  Systems  Management  College  Press,  Fort  Belvoir,  VA,  November 
1995. 

1 1 .  Upton,  Bert,  Joint  Logistics  Commander — Acquisition  Initiatives:  Sixth  Edition,  Oct 
1995,  Defense  Acquisition  Deskbook,  Version  1.3,  31  December  1996. 

12.  Department  of  the  Navy,  Acquisition  Planning  Guide,  April  1992. 

13.  Naval  Air  Systems  Command,  Procurement  Initiation  Document  Guide,  August  1995 
Edition. 

14.  Miller,  B.,  Interview  with  Dr.  Michael  Hammer  -  Public  Sector  Reengineering, 
Government  Technology  Magazine,  September  1995. 

15.  Commercial  Practices  for  Defense  Acquisition;  Guidebook,  Defense  Systems 
Management  College,  Fort  Belvoir,  Virginia,  January  1992. 

16.  Hearn,  Emmet  E.,  Federal  Acquisition  and  Contract  Management,  Hearn  Associates, 
Los  Altos,  CA,  1996. 

17.  Cleland,  David  E.,  et  al,  Military  Project  Management  Handbook,  McGraw-Hill,  Inc, 
1993. 

18.  Bregard,  Richard  W.,  &  Chasteen,  Taylor,  Implementing  Integrated  Product 
Development:  A  Project  Managers  Perspective,  Acquisition  Review  Quarterly,  Fall, 
1996. 

19.  Rhoads,  Dean,  Is  DAWIA    Worth  It?  An  Approach  to  Analyzing  the  Impacts, 

Acquisition  Review  Quarterly,  Spring  1 995 . 

102 


20.  Harman,  Beryl  A.,  From  the  Constitution  to  FAStA — Origins  of  Acquisition  Reform, 
Program  Manager,  September-October  1995. 

21.  U.S.  General  Accounting  Office,  Acquisition  Reform:  Implementation  of  Title  V  of  the 
Federal  Acquisition  Streamlining  Act  of  1994,  GOA/NSIAD-97-22BR,  October, 
1996. 

22.  Valore,  Frances  M.,  AAI  PAT  Introduces  the  Acquisition  Deskbook,  Program 
Manager,  July- August  1995. 

23.  Department  of  Defense,  Mission  Need  Statement,  Standard  Procurement  System, 
Signed  5  May  1995. 

24.  Department  of  Defense,  Standard  Procurement  System  Program  Baseline  Plan,  June 
1995. 

25.  U.S.  General  Accounting  Office,  Information  Technology  Investment:  A 
Governmentwide  Overview,  GAO/ATMD-95-208,  July  1995. 

26.  U.S.  General  Accounting  Office,  Information  Technology  Investment:  Agencies  Can 
Improve  Performance,  Reduce  Cost  and  Minimize  Risks,  GAO/ATMD-996-64, 
September  1996. 

27.  U.S.  General  Accounting  Office,  Executive  Guide-Improving  Mission  Performance 
Through  Strategic  Information  Management  and  Technology:  Learning  from  Leading 
Organizations,  GAO/ATMD-04-115,  May  1994. 

28.  Software  Technology  Support  Center,  Guidelines  for  Successful  Acquisition  and 

Management  of  Software  Intensive  Systems  (Version  2.0),  March  1996. 

103 


29.  Gibbs,  W.  Wayt,  Software 's  Chronic  Crisis,  Scientific  American,  September  1994. 

30.  Davenport,  Thomas  H.,  Process  Innovation:  Reengineering  Work  through 
Information  Technology,  Harvard  Business  School  Press,  1993. 

31.  U.S.  General  Accounting  Office,  Business  Process  Reengineering  Assessment  Guide, 
GAO/AIMD-10.1.15,  Version  3,  May  1997. 

32.  Department  of  the  Navy,  DON— Acquisition  Planning  Guide,  April  1992. 

33.  Senn,  James  A.,  Information  Technology  in  Business,  Prentice  Hall,  New  Jersey, 
1995. 

34.  Department  of  Defense,  Under  Secretary  of  Defense  (Acquisition  and  Technology), 
Good  Judgment  in  the  Competitive  Procurement  Process,  Memorandum,  28  June 
1995. 

35.  Khoshafian,  S.,  and  Buckiewicz,  M.,  Introduction  to  Groupware,  Workflow,  and 
Workgroup  Computing,  John  Wiley  &  Sons,  Inc.,  1995. 

36.  Microsoft  Corporation,  Getting  Results  with  Microsoft  Office  for  Windows  95,  1995. 

37.  Nissen,  Mark  E.,  Reengineering  the  RFP  Process  through  Knowledge-Based  Systems, 
Acquisition  Review  Quarterly,  Winter  1997. 

38.  U.S.  General  Accounting  Office,  Executive  Guide:  Effectively  Implementing  the 
Government  Performance  and  Results  Act,  GAO/GGD-96-118,  June  1996. 

39.  Hewitt,  Clyde,  Getting  to  the  On-Ramp  of  the  Information  Superhighway,  Acquisition 
Review  Quarterly,  Winter  1996. 


104 


40.  Harwood,     Doreen,    Defense    Acquisition    Deskbook—An    Acquisition    Reform 
Unqualified  Success,  Program  Manager,  January-February,  1997. 

41.  Secretary  of Defense,  Memorandum:  Reducing  Cycle  Times,  14  September  1994. 

42.  Mintzberg,  Henry,  and  Quinn,  James  B.,  The  Strategy  Process:  Concepts,  Contexts, 
Cases,  Third  Edition,  Prentice  Hall,  1996. 

43.  Office    of  Management    and    Budget,    OMB    Circular   A- 109:    Major    Systems 
Acquisitions,  5  April  1976. 

44.  Defense  Acquisition  Deskbook  Joint  Program  Office,  Defense  Acquisition  Deskbook, 
Version  1.4,31  March  1997. 

45.  Department     of    the     Navy,     Naval    Air     Systems     Command    Home     Page, 
http:/www.navair.navy.mil,  21  February  1997. 

46.  Department  of  the  Navy,  Naval  Air  Systems  Command,  NAVA1R  ACQUISITION 
GUIDE,  17  May  1995. 

47.  Department    of  the   Navy,    Naval    Air    Systems   Command    Instruction   4200.37, 
Procurement  Process,  16  May  94. 

48.  Department    of  the   Navy,    Naval    Air    Systems    Command    Instruction   4200.36, 
Acquisition  Plans,  26  January  1994. 

49.  Department  of  the  Navy,  Naval  Air  Systems  Command,  Contract  Competency:  Team 
Management  Plan,  February  1997. 


105 


106 


INITIAL  DISTRIBUTION  LIST 

1.  Defense  Technical  Information  Center 2 

8725  John  J.  Kingman  Rd.,  STE  0944 

Ft.  Belvoir,  Virginia  22060-6218 

2.  Dudley  Knox  Library 2 

Naval  Postgraduate  School 

411  Dyer  Rd. 

Monterey,  California  93943-5101 

3  Professor  David  V.  Lamm 5 

Code  SM/LT 

Naval  Postgraduate  School 

Monterey,  CA  93943-5000 

4.  Professor  Mark  E.  Nissen 2 

Code  SM/NI 

Naval  Postgraduate  School 
Monterey,  California  93943-5000 

5 .  Professor  Janice  M.  Menker 2 

Code  SM/MJ 

Naval  Postgraduate  School 
Monterey,  California  93943-5000 

6.  LCDRMarkE.  St.  Moritz 2 

43974  White  Cedar  Lane 

California,  MD  20619 


107 


n        483NPG 
«J  TH 


10/99  22527-200  ; 


